AltME groups: search

Pekr, if you are interested what action!s and native!s are currently 
available, I wrote simple parser that goes thru %actions.reds and 
%natives.reds and outputs list of all implemented functions.

The source code should be easily parse-able, so the list of functions, 
native, actions, ops could be extracted and pretty-printed as a web 
page. IIRC, someone tried to make such script but I didn't see any 
result yet.

There is as I read this a different issue. Dock want Red to be as 
complete as posible, Kaj wants it to officially useable. Kaj really 
needs UTF-8 (and or Latin-1) character support, for getting this, 
I guess this has to do with the Syllable operating system amongst 
others.

I would like Red to support time and random functions as natives 
and (Gregg is one of your mezz funcs REJOIN ? I want that too) be 
able to connect to a MySQL database so I can dump PHP for some webdevelopment.

Besdies that we all love to see a VID (like) solution for display 
and creating apps. 

We have to be patient agreed 100% amongst everybody? Where the roadmap 
mentions all things to progress Red, above things are not on that 
list. I want Red to have enough to make it useable in production 
and after that expand, imho that is the way to really attrackt more 
funding/enthousiast programmers and make sure current support does 
not fade/ loose interest.

Arnold, isn't that what HELP (or the ? short) is used for? WHAT seems 
to "Prints a list of globally-defined functions.".

Especially what good is the #system-global for then? Ah like #system 
in R/S documentation chapter 17
Also from this:

It will be possible to export some Red/System functions to be callable 
from the Red language layer. The method for such export hasn't been 
decided yet. Among possible options, it can be:

A special attribute 
in header that will list the functions to export
A function's attribute 
in the specification block
A compiler directive


I can taste that the integration is just around the corner. But which 
one? :)

Well, my gripes were with the architecture a bit - all those functions 
with replicated names - do-servise, open-service, close-service. 
IIRC, old IOS used rsp-* functions, it was easy to list in help, 
and it used even rsp:// port scheme IIRC. Other thing I did not like 
much was, that the code seems to be plain pure parse code, but surely 
if the need is there, it could be abstracted. Carl admitted, that 
he would somehow change the design, no specific things I remember 
about his thoughts though ...

Apart from Unicode, we have no comparison over REBOL2 for new and 
better feature which could motivate the programmer.
 - wrong again, you surely heard about:
- essentially all cycles being natives in R3
- money implemented as a "truly decimal" format

- functions implemented differently to be compatible with multithreading, 
etc.
- closures implemented natively
- Parse improved significantly
- R3GUI improved
- new modules feature
- I do not even have the time to list all...

Great, will setup a page the next days, to list the current extensions 
with description/download link to get a better overview.

Just running the first embedded POSIX prototype here with a bunch 
of usefull functions like pid handling, fork, nanosleep, popen, execve, 
sig, pipe etc.

Robert: you have two primitives send & recv. Both _block_ per default: 
send until there it manages to enqueue the message in an internal 
buffer, recv until it fully read a message. You call both functions 
with a NOBLOCK flag, in which case they won't block but return immediately, 
with an EAGAIN status code in case they did not manage to write/read 
anything. Finally, you also have a poll primitive, to which you pass 
a list of sockets you are interested in and an (optional) timeout. 
Poll returns you a list of sockets which are "active", i.e. which 
can be safely read from (or written to) without blocking.

I have a slightly modified help, that does not evaluate functions 
in objects and ports and that also dumps ports like objects.
>> a: open http://www.rebol.com
connecting to: www.rebol.com
>> help a
A is a port of value:
   scheme          word!     HTTP
   host            string!   "www.rebol.com"
   port-id         integer!  80
   user            none!     none
   pass            none!     none
   target          none!     none
   path            none!     none
   proxy           object!   [host port-id user pass type bypass]
   access          none!     none
   allow           none!     none
   buffer-size     none!     none
   limit           none!     none

   handler         object!   [port-flags open-check close-check write-check 
   ini...
   status          word!     file
   size            integer!  0
   date            date!     6-Nov-2006/21:26:44
   url             string!   "http://www.rebol.com/"

   sub-port        port!     make port! [ scheme: 'tcp host: "www.rebol.com" 
   po...
   locals          object!   [list headers querying]

   state           object!   [flags misc tail num with custom index 
   func fpos i...
   timeout         integer!  30
   local-ip        none!     none
   local-service   none!     none
   remote-service  none!     none
   last-remote-service none! none
   direction       none!     none
   key             none!     none
   strength        none!     none
   algorithm       none!     none
   block-chaining  none!     none
   init-vector     none!     none
   padding         none!     none
   async-modes     none!     none
   remote-ip       none!     none
   local-port      none!     none
   remote-port     none!     none
   backlog         none!     none
   device          none!     none
   speed           none!     none
   data-bits       none!     none
   parity          none!     none
   stop-bits       none!     none
   rts-cts         logic!    true
   user-data       none!     none
   awake           none!     none

Is there interest in including in the new release?

hmm... seems I forgot there are some LIST-VIEW 0.0.29 only functions 
used in Tester. maybe I should do a release soon....

The Logo interpreter I did (early in REBOL for me) allowed user defined 
functions; basically it just added things to the list of parse rules 
it knew about, naive, but semi-functional. :-)

; I liked this feature of ICON/UNICON where a func can have an initially 
block so I have this in REBOL
initial: func [wd [word!] /list /local functions]
  [
    functions: []
    if list [return functions]
    f: find functions wd
    either (found? f) 
      [return false] 
      [append functions wd return true]
  ]    


initially: func ['wd [lit-word!] blk [block!]][
    if (initial wd) [do blk]
]
; and to test initially
test: func [str [string!] /local prefix [string!]][
    prefix: ""
    initially 'test [prefix: "tested "]
    print [prefix str]
]
; which runs as, say
test "this"
; first time giving "tested this" and thereafter "this"
; thoughts on whether useful enough to go into the org library ?

That feature you mention is the word-active feature. It's also what 
causes functions to be evaluated. It's sort of like putting a function 
reference in the first position of the list in Scheme rather than 
the other positions.

I get the feeling that I'm going to want to have an analysis tool 
which will read through the functions, find any variable: assignments, 
and ensure they're in the local list unless there's some sort of 
indication they should be global.  Because it seems relatively uncommon 
that I would, inside a function, set things in the global space. 
 I'd be happy to use something wordier (set?) for that

Diss'ing IDE's might alienate some Smalltalk folk.  I cannot imagine 
maintaining an application suite such as I deal with everyday without 
an IDE.  I just wish it was not eclipse ...  Of course only wimps 
used a Disk Operating System and real men code in machine codes only 
... and real pro's dictated their SNOBOL punch cards to lovely assistants 
...  and ANT scripts are for sissies.  Some must have ridiculed Tcl, 
Expect and TK in their day ... but if my IDE can facilitate my efforts 
to systematically (key word there) shrirnk company''s codebase as 
it becomes more reliable with better test coverage then maybe a refactoring 
browser would be a good tool after all.  Even better if it is an 
integrated part of the IDE, as in Dolphin Smalltalk or Squeak Smalltalk 
or Smalltalk/X or Cincom Visual Smalltalk.  Not that I couldn't survive 
on grep and diff's.  But once the codebase is too large for any one 
person to author or maintain on their lonesome, a tool that remebers 
what you did last and where can be a god-send.  If you want to know 
hell without an IDE join an actuarial department working in APL. 
 There you don't even know if they have talent: you just hope most 
of it works as each quarter rolls around and try to survive year-end. 
 But you know they're smart, cuz after all, they're actuaries - and 
look at all that APL code in all those files ... of course a few 
of them look back wistfully at their student days in C with Borland's 
decent IDE.  REBOL [
    File: %vid-usage.r
    Date: 09-Jan-2004   
    Title: "VID Usage"
    Purpose: "VID Usage Tutorial with Runnable Examples"
    Version: 1.2.1
    Author: "Cybarite"
    Edits: RobertS
    Source: {
        Based on %easy-vid.r by Carl Sassenrath.

        Clips from various sites including email that are attributed in the 
        section
        }
    library: [
        level: 'intermediate
        platform: 'all
        type: [tutorial]
        domain: [gui]
        tested-under: [view 1.2.8.3.1 on W2K]
        support: none
        license: none
        see-also: none
    ]
]
 
flash "Fetching image..."
read-thru/to http://www.rebol.com/view/demos/palms.jpg%palms.jpg

read-thru/to http://www.rebol.com/graphics/reb-logo.gif%rebo-logo.gif
read-thru/to http://www.rebol.com/view/bay.jpg%bay.jpg
pic: %palms.jpg
unview

customer: make object! [  ; this sets a default customer object in 
case the user does not push the samples in order
        name: "Rosetta Stone"
        date-of-birth: 14-March-1959        
]

stylize/master [text-note: txt maroon bold]         ; this sets a 
default for users who run the samples out of order
; polished is an image that is embedded in this script file
; so that no outside files need to be loaded.
; This technique is used in many of the REBOL samples

polished: load #{      
89504E470D0A1A0A0000000D49484452000000670000003808020000006FFB71
8C0000001374455874536F667477617265005245424F4C2F566965778FD91678
0000039B49444154789CCD9BD14E2B310C44F3FFFF521E2AC1C395E00589EF02
5DD8D226713C339EECBD928510A4893D3EF67AB76D7B7E79FEB2D73FAFBDBD1D
36FEEBAF7DBF70FEDABABD0D56F0E1B6E0B6FED7AE81050B2E4F97AF9FED6185
45022048CA2C6920361F1336580B35A63C4E4F12808D378124CE9C81880B186C
14175A1DE9C0C2A2E785B6B64CA62EF6C626330250A932064CB984F3358FA77F
BC7F8CD657685E5FB03415A34B9E3226C1484A1ACA6DB6974597699EFB6C2F4E
C44B92E17454A309F14F348DDD4D5B98195BB2AF6B7E4E545B57FEBAE0415DA0
43EFE62C70B196362285D74C35F0782ECF26A0FC8492E20EAAED6CC35ACE13FC
61646467C69D5715EA4F9D3725B1703BF45AB2768A9D5F59CA6E716E5A747CBF
23D6A7E418C2C53C6EB440FCE803B106E6D94C8AAF4B42694871B9FB237035C8
70E5A0200D4A7E4553E952A6F435BA247DD4B83A5DB18D26AA4D5E39E0CA4107
7B0F86C7F19EC685B5EFE57D28E02E411CC2238C0304B5065D26DCC1DA9A02FC
CE4EBD19A0C58D9BE039179086B6DB20519A1F5C8194071DBB115703B996FF37
4BE0F5AA269B18CFC9C6CC1FC3D5A0D6B62C6AEA112236F38195B88DF12F9C9B
B45B1C6C637B161E1D5BCF6D8807A0437366CB21D90462F2BD3E827C96CB0483
D67B99916407E99E69FD12F46A50C973856268A5DC345259837D8827E00FF890
452D0B5D0D38932F3C65B9614B4F720901B96565DCCBD7236B7C66B650868D08
9BFA26EBB36DCAA5E3B120339E5EBE3B468E6B68FB3041E79229047367ADDC14
F7B376F26B2722024A41998813A04CB91A475C11C9054536473CA3F7365C0D30
9E65A0BA6D5977CFEE030BD626B9E2E5DFE76E51AFF9CADA6308F899C76E756A
03D4796E80532E986D273B71CEA8D81672739E0F1B329F8E999D0D9D04080769
CABC1D21260C2BB8E43D2A9D70BE3A2207D66EA09E5BCAFFB742F9F0A0C37677
222CFE9B7C2865192B3FAC5988E0385747334BD8288041E0DFBF4F2AD44804B4
6DADAF2BE98C5D02458059B3571CA91481B09580A9D6E827B184DD3756D6BF7E
7376F81ED59E46633384296A9A4BA7D4E3B8CBD3E566F1948B754731E0EBC41B
246774BD7BBBCA612D8CA7CC85A7C1ED093B75721DCED1D7E279871668830AE7
B782F5E9FDE4918360C9F666A6F61647F2EDB342A2FA3F6E9B0C8AC2699B9B3F
53847BB992B5707FDE5B6D721EA3EB55E3D8190D8BD998923A68917BE3FEDD32
EE1BDCA216275C1CCFBD0A07F35A40A6CC05A1357E6BF512D26DC470BAC927A3
B0078A42DD22E10000000049454E44AE426082
}
content: {VID Usage - REBOL Visual Interfaces


===Updates

--01-Apr-2008


* Fixed oddity with last item on stylesheets which was locking up 
some versions of VIEW

---09-Jan-2004

* Fixed slider initialize. 

* Focus section was not parsed out. --- fixed

* Fixed some text errors for the parsing of ===


---07-Jan-2004

* Revived vid-usage.r 

* added more examples from the script library

* manage source as vid-usage.leo an outliner file

---12-August-2001

Added supply examples. See:

!List/Supply

!List With Supplied Data

!Supply List With Scroll

---13-August-2001

!Add Subpanel example ported by Anton

===Caveats

---Work In Progress


This is a work in progress. Whether the progress will continue depends 
on the feedback.

---All Rights Reserved


The work is based on the documentation of REBOL View provided by 
REBOL Technology and its mailing list.

All rights to this documentation remain the property of REBOL Technology.

---Plagiarized Examples


Things are shamelessly plagiarized.  There are many experts on the 
mailing list whose work is included here; most notably the examples 
from the REBOL documentation.

---Approach


The approach that this document uses is to use REBOL/View/VID to 
demonstrate its abilities and give a visual tutorial. To enable this 
some changes have been made to the core %easyvid.r program from Carl 
Sassenrath. A scoll bar was added to the right pane because it was 
just too difficult to constrain the examples to the screen real estate 
that was available.

---Order Order


The order of the items needs some work. The easyvid presentation 
approach today does not allow for the drilling down and expansion 
of an outline tree which is needed for a large amount of documentation.


The preferred approach is to put a multi-level tree for navigation 
purposes and then allow navigation up and down the tree. 


===To Do

* make this a true outline tree

* re-organize it better


* update as requested and as possible by suggestions on AltME's REBOL 
world under group EasyVID

* correct numerous flaws


* better scrolling implementation using the updates that have been 
used in other examples such as Didier's %delete-email.r


* allow clipping to clipboard like AltME does on a row for the source 
examples




===Introduction to VID

With REBOL/View it's easy and quick to create your own user
interfaces. The purpose of this tutorial is to teach you the
basic concepts or REBOL/View interfaces in about 20 minutes.

VID is REBOL's Visual Interface Dialect.  A dialect is an
extension of the REBOL language that makes it easier to express
or describe information, actions, or interfaces.  VID is a
dialect that provides a powerful method of describing user
interfaces.

VID is simple to learn and provides a smooth learning curve from
basic user interfaces to sophisticated distributed computing
applications.


---Creating VID Interfaces

VID interfaces are written in plain text. You can use any text
editor to create and edit your VID script. Save your script
as a text file, and run it with REBOL/View.

!Note: Using a word processor like Word or Wordpad is not
recommended because files are not normally saved as text.
If you use a word processor, be sure to save the output
file as text, not as a document (.doc) file.


Recommendation: Look at TextPad from http://www.textpad.com




===Minimal VID Example

Here is a minimal VID example.  It creates a window that
displays a short text message.  Only one line of code
is required:

    view layout [text "Hello REBOL World!"]

You can type this line at the REBOL console prompt, or save
it in a text file and run it with REBOL.  If you save it
as a file, the script will also need a REBOL header. The
header tells REBOL that the file contains a script. Here
is an example of the script file with a header:

    REBOL [Title: "Example VID Script"]

    view layout [text "VID Example!"]

You can also add buttons and other gadgets to the script. The
example below displays a text, list of files, and a button:

    view layout [
        h2 "File List:"
        text-list data read %.
        button "Great!"
    ]

!Click on the examples above to see how they will appear on your
screen.  Click on their close box to remove them.  All of the
examples that follow can be viewed this way.


===Window Management


The code that displays the examples also shows how to manage the 
number of windows that are open.


Look at the show-example block in the code near the end of this script.


The location of the example window is also managed here by keeping 
track of the co-ordinates for the sample. After the sample window 
is moved, the next use will open at the same location.



===Pre-loaded Images


For this script, the image which represented a Portable Network Graphic
definition of an image is held in the script and loaded.


For a small number of graphics, this can achieve some packaging and
performance benefits.


The image "polished" is used through the script to achieve the polished 
steel
look that is one the outer frame.

    backtile polished orange
    button 200x50 "Polished Steel Look" polished 


===Two Basic Functions

Two functions are used to create graphical user interfaces
in REBOL: VIEW and LAYOUT.

The LAYOUT function creates a set of graphical objects.  These
objects are called faces.  You describe faces with words and

values that are put into a block and passed to the LAYOUT function.

The VIEW function displays faces that were previously created by
LAYOUT. The example below shows how the result of
the LAYOUT function is passed to the VIEW function, and the
interface is displayed.

    view layout [
        text "Layout passes its result to View for display."
        button "Ok"
    ]

Click on the above example to view it.

!Note: the block provided to a layout is not normal REBOL code,
it is a dialect of REBOL.  Using a dialect makes it much easier
to express user interfaces.



===Styles

Styles describe faces.  The examples above use the text and
button styles to specify a text line and a button. REBOL has
40 predefined face styles. You can also create your own custom
styles.  Here are a few example styles:

    view layout [
        h1 "Style Examples"
        box brick 240x2
        vtext bold "There are 40 styles built into REBOL."
        button "Great"
        toggle "Press" "Down"
        rotary "Click" "Several" "Times"
        choice "Choose" "Multiple" "Items"
        text-list 120x80 "this is" "a list" "of text"
        across
        check
        radio radio
        led
        arrow
        below
        field "Text Entry"
    ]


The words like backdrop, banner, box, text, and button are styles.

===Facets

Facets let you modify a style.  For instance, you can change the
color, size, text, font, image, edge, background, special
effects, and many other facets of a style.

Facets follow the style name.  Here is an example that shows
how you modify the text style to be bold and navy blue:

    view layout [txt bold navy "Facets are easy to use."]

The words bold and navy are not styles.  They are facets that
modify a style. Facets can appear in any order so you don't
have to remember which goes first.  For example, the line
above could be written as:

    view layout [txt "Facets are easy to use." navy bold]

Many facets that can be specified.  Here is an example that
creates bold red text centered in a black box.

    view layout [txt 300 bold red black center "Red Text"]

You can create facets that produce special effects, such
as a gradient colored backdrop behind the text:

    view layout [
        vtext bold "Wild Thing" effect [gradient 200.0.0 0.0.200]
    ]

===Custom Styles

Custom styles are shortcuts that save time.  When you define a
custom style, the facets you need go into the new style.  This
reduces what you need to specify each time you use the style,
and it allows you to modify the look of your interface by
changing the style definitions.

For example, here is a layout that defines a style for red
buttons.  The style word defines the new style, followed by
the old style name and its facets.

    view layout [
        style red-btn button red
        text "Testing red button style:"
        red-btn "Test"
        red-btn "Red"
    ]

So, if you wanted to create a text style for big, bold,
underlined, yellow, typewriter text:

    view layout [
        style yell tt 220 bold underline yellow font-size 16
        yell "Hello"
        yell "This is big old text."
        yell "Goodbye"
    ]


===Master Stylesheet 

REBOL holds its styles in a master stylesheet. When you are
sure that you want to share them without having to add the
style sheet line then do it as follows:

First add the style to the master sheet:

    button 200x50 "Define text-note as maroon bold text" [stylize/master 
    [
        text-note: txt maroon bold      
    ]]

    button 200x50 "Define text-note as white italic text" [stylize/master 
    [
        text-note: txt white italic     
    ]]

Then invoke it:

    view layout [
        across
        size 200x200

        return text-note "This shows a master stylesheet style in use." 

        return text-note "This shows another usage of the same style."

        return text-note "If you want to see the other style displayed, click 
        the Add Style section again and then use the other button"
    ]
    
    
===Note About Examples

!From this point forward, all examples will assume that
the view and layout functions are provided.  Only the layout
block contents will be shown.  To use these examples in your
scripts, you will need to put them in a layout block, as was
shown earlier.

For example, code that is written as:

    view layout [button red "Test it"]

will now appear as:

    button red "Test it"


===Face Sizes

The size of a face depends on its style.  Most styles, such as
buttons, toggles, boxes, checks, text-lists, and fields, have a
convenient default size.  Here are some examples.

    button "Button"
    toggle "Toggle"
    box blue
    field
    text-list

If no size is given, text will automatically compute its size,
and images will use whatever their source size is:

    text "Short text line"
    text "This is a much longer line of text than that above."
    image %palms.jpg

You can change the size of any face by providing a size facet.
The size can be an integer or a pair.  An integer specifies
the width of the face.  A pair specifies both width and height.
Images will be stretched to fit the size.

    button 200 "Big Button"
    button 200x100 "Huge Button"
    image %palms.jpg 50x50
    image %palms.jpg 150x50

===Color Facets

Most styles have a default color.  For example the body of
buttons will default to a teal color.  To modify the color of
a face, provide a color facet:

    button blue "Blue Button"
    h2 red "Red Heading"
    image %palms.jpg orange

Colors can also be specifed as tuples. Each tuple contains three
numbers: the red, green, and blue components of the color. Each
component can range from 0 to 255. For example:

    button 200.0.200 "Red + Blue = Magenta" 200
    image %palms.jpg 0.200.200 "Green + Blue"

Some face styles also allow more than one color.  The effect of
the color depends on the style.  For text styles the first color
will be used for the text and the second color for the background
of the text:

    txt "Yellow on red background" yellow red
    banner "White on Navy Blue" white navy

For other styles, the body of the face is the first color, and
the second color will be used as its alternate.

    button "Multicolor" olive red
    toggle "Multicolor" blue orange
===Layout Commands


To drop user interface elements on the canvas according to VIDs 
directional layout controls 

---Across

You are placing elements in a row orientation
    
    across 
    return button "A" button "B" button "C"
    return button "D" button "E" button "F"
    

---Below

You are placing elements in a column orientation

    below 
    return button "A" button "B" button "C"
    return button "D" button "E" button "F"

---Mix

You can mix the directional controls 

    across 
    return button "A" button "B" 
    below button "C" 
    across button "D" button "E" button "F"


---Padding


The pad keyword creates extra padding between styles. It uses a pair 
or integer value. When it is an integer, spacing is created either 
horizontally (across) or vertically (below). When it is a pair, the 
spacing will be created both horizontal and vertically. The following 
example illustrates both uses. First, the buttons "one" and "two" 
are padded with an integer representing 40 pixels in one direction. 
Then the buttons "three" and "four" are padded with a pair representing 
40x40 pixels. 

    across 
    button "one" pad 40 button "two" return 
    button "three" pad 40x40 button "four" 


Padding can be negative.
    
        backtile polished orange
        pad 200x200 button "A"
        pad -100x-100 button "B"
        
---Guide

A guide is a virtual alignment control

      title "Buttons Without A Guide" 
    button "one"   button "two"  return 
    button "three" button "four" return 
    button" five" button "six" 

With an implicit guide location

    title "Buttons With An Implicit Guide Location" 
    guide 
    button "one"   button "two"  return 
    button "three" button "four" return 
    button" five" button "six" 

With an explicit guide location

    across title "Buttons With An Explicit Guide Location"
    guide 55x100 
    button "one"   button "two"  return 
    button "three" button "four" return 
    button" five" button "six" 
    
===Tabstops

Tabs can be used for alignment.

---Across

    tabs 200 ; sets tabs every 200 pixels   
    across button 20 "A" tab button 20 "B" tab button 20 "C" 
    tabs 100 ; sets tabs every 100 pixels   
    return button 20 "D" tab button 20 "E" tab button 20 "F"
    
---Below

    tabs 200 ; sets tabs every 200 pixels   
    below button 20 "A" tab button 20 "B" tab button 20 "C" 
    tabs 100 ; sets tabs every 100 pixels   
    return button 20 "D" tab button 20 "E" tab button 20 "F"

---Explicit Settings

Tabstops can be set at explicit values 

    tabs [100 124  166 212 300]

    across tab button 20 "A" tab button 20 "B" tab button 20 "C" tab 
    button 20 "D"
    
===Color Facets

Most styles have a default color.  For example the body of
buttons will default to a teal color.  To modify the color of
a face, provide a color facet:

    button 200 blue "Blue Button"
    h2 red "Red Heading"
    image polished orange

Colors can also be specifed as tuples. Each tuple contains three
numbers: the red, green, and blue components of the color. Each
component can range from 0 to 255. For example:

    button 200.0.200 "Red + Blue = Magenta" 200
    image polished 0.200.200 "Green + Blue"


Some face styles also allow more than one color.  The effect of the 
color depends on the style.  For text styles the first color will 
be used for the text and the second color for the background of the 
text:

    txt "Yellow on red background" yellow red
    title "White on Navy Blue" white navy


For other styles, the body of the face is the first color, and the 
second color will be used as its alternate.

    button 200 "Multicolor" olive red
    toggle 200 "Multicolor" blue orange


From the mailing list, there was a problem reported in changing button 
color:

    view layout [
        b: button "New color" [
            b/color: random 255.255.255 
            show b
        ]
    ]
    

And the answer was that the gradient of the color was preventing 
this change from working:


    style color-changing-button button 0.0.0        ; new style overwrites 
    gradient effect
    b: color-changing-button "New color" [
        b/color: random 255.255.255 
        show b
    ]

===Text Facets


Most faces will accept text to be displayed.  Even graphical faces 
can display text.  For example, the box and image faces will display 
text if it is provided:

    box blue "Box Face"
    image polished "Image Face"


Most button faces will accept more than one text string. The strings 
will be shown as alternates as the face is selected.

    button 200 "Up" "Down"
    toggle 200 "Off" "On"
    rotary 200 "Red" "Green" "Blue" "Yellow"
    choice 200 "Monday" "Tuesday" "Wednesday" "Thursday" "Friday"

    text-list 200 "Monday" "Tuesday" "Wednesday" "Thursday" "Friday"


When other datatypes need to be displayed as text, use the form function 
to convert them first:

    button 250 form now
    field form first read %.
    
===Normal Text Style


Normal text is light on dark and can include a number of facets to 
set the font, style, color, shadow, spacing, tabbing, and other attributes.

    text "Normal"
    text "Bold" bold
    text "Italic" italic
    text "Underline" underline
    text "Bold italic underline" bold italic underline
    text "Big" font-size 32
    text "Serif style text" font-name font-serif
    text "Spaced text" font [space: 5x0]

Text also includes these predefined styles:

    title "Title" 200
    vh1 "vh1"
    vh2 "vh2"
    vh3 "vh3"
    vh4 "vh4"
    label "Label"
    
    
===Document Text Style


Document text is dark on light and can also include a number of facets 
to set the font, style, color, shadow, spacing, tabbing, and other 
attributes.

    txt "Normal"
    txt "Bold" bold
    txt "Italic" italic
    txt "Underline" underline
    txt "Bold italic underline" bold italic underline
    txt "Big" font-size 32
    txt "Serif style text" font-name font-serif
    txt "Spaced text" font [space: 5x0]

Document text also includes these predefined styles:

    title "Centered title" 200
    h1 "Heading 1"
    h2 "Heading 2"
    h3 "Heading 3"
    h4 "Heading 4"
    tt "Typewriter text"
===Text Entry Fields


Text input fields accept text until the enter or tab key is pressed. 
 A text input field can be created with:

    field

To make the field larger or smaller, provide a width:

    field 30
    field 300

Fields will scroll when necessary.


Larger amounts of text can be entered in an area.  Areas also accept 
an enter key and will break lines.

    area

You can also specify the area size:

    area 160x200


To force the text in an area to wrap rather than scroll horizontally, 
provide the wrap option:

    area wrap
===Text Setting


To set the value of a text field under program control, use /text: 
e.g.

    across backtile polished
    return t1: txt      200 "This is some original text"
    return f1: field    200 "Some field text"   
    return a1: area  {Some original area text.} wrap 200x80
    return button 200 "Change Text" [
        t1/text: "Some different text" 
        f1/text: "Some new field text"

        a1/text: {Some wrapping text in the^/ area field to^/ show that this^/ 
        is supported}
        show [t1 f1 a1]
    ]
    
===Text Lists

Text lists are easy to create.  Here is an example.

    text-list "Eureka" "Ukiah" "Mendocino"

You can also provide it as a block:

    text-list data ["Eureka" "Ukiah" "Mendocino"]


Almost any type of block can be provided. Here is a list of all the 
files in your current directory:

    text-list data read %.

Here is a list of all the words REBOL has scanned:

    text-list data first system/words
===Scrolling Text List


A style to allow maintenance of lists from Brett Handley on the REBOL 
list:

        style updatable-text-list text-list
        with [
            update-slider: does [
                sld/redrag lc / max 1 length? head lines
            ]
        ]

        tl: updatable-text-list 300x100 data copy system/locale/months
        button  300x20 "Delete first entry on the list" [
            remove tl/data tl/update-slider show tl
        ]
        button 300x20 "Append the 'now' timestamp to list" [
            append tl/data mold now tl/update-slider show tl
        ]
===Text List Picked Values

    list-of-letters: text-list "a" "b" "c" "d" "e" 
    button 200  "Pick Item 3" [
        clear list-of-letters/picked 

        append list-of-letters/picked pick list-of-letters/data 3 
        show list-of-letters
    ]
===Images

By default an image will be scaled to fit within a face.

    image 60x60 polished
    image polished red

Images can be framed in a number of ways:

    image 100x100 polished frame blue 5x5
    image 100x100 polished bevel
    image 100x100 polished ibevel 6x6

Most other faces can accept an image as well as text:

    box 100x100 polished
    button "Button" polished purple
    toggle "Toggle" polished blue red
    field bold  "This is a field." polished effect [emboss tile]

    field bold "This is another field." polished effect [brighten 100]

The image can be provided as a filename, URL, or image data.



===Backdrops

A backdrop can be a color, an effect, an image, or a combination
of the three.  For example a backdrop color would be written as:

    backdrop navy
    title "Color Backdrop" gold

To create a backdrop effect provide it on the line:

    backdrop effect [gradient 1x1 0.0.100 100.0.0]
    title "Gradient Backdrop" gold

A backdrop image can be a file, URL, or image data:

    backdrop polished
    title "Image Backdrop" red

The backdrop image can be colorized:

    size 400x500 
    backdrop polished blue
    title "Blue Image Backdrop"

The image can include an effect:

    backdrop polished effect [fit gradcol 1x1 100.0.0 0.0.250]
    title "Gradient Image Backdrop"
    
===Backtile

To make a backdrop use a tile effect there are two options:

    backdrop polished effect [tile]
    banner "This shows a backdrop with a tile effect"
    
or

    backtile polished
    banner "This demonstrates backtile"


Note the difference between:

    size 400x500 
    backdrop polished
    banner "Here one image is stretched to cover the canvas"

and

    size 400x500 
    backtile polished
    banner "Here one image is repeated to cover the canvas"
    
===Effect Facets


A range of effects are supported for faces.  All of these effects 
are performed directly on the face when it is rendered. Here are 
examples of a few possible effects in top to bottom then left to 
right order:

    style polished-steel image 80x60 polished 
    polished-steel effect [flip 1x1]
    polished-steel effect [rotate 90]
    polished-steel effect [reflect 1x1]
    polished-steel effect [crop 0x50 120x60 fit]
    polished-steel effect [grayscale]
    polished-steel effect [invert]
    polished-steel effect [difference 200.0.0]
    polished-steel effect [tint 80]
    return
    polished-steel effect [contrast 50]
    polished-steel effect [brighten 50]
    polished-steel effect [sharpen]
    polished-steel effect [blur]
    polished-steel effect [colorize 204.0.0]
    polished-steel effect [gradcol 1x1 150.0.0 0.0.150]
    polished-steel effect [gradmul 0x1 0.100.0]
    polished-steel effect [grayscale emboss]


Effects can be used in combination to create other interesting results. 
 However, keep in mind that the computations are performed in real 
time.  If complex combinations are required, a temporary image should 
be created with the to-image function.


===Actions


An action can be associated with almost any face. To do so, follow 
the face style with a block:

    button "Test" [alert "test"]


The block is used as the body of a function that is passed the face 
and the current value (if the face has one).  For example:

    toggle "Toggle" [alert form value] 
    rotary "A" "B" "C" [alert form value]
    text "Click Here" [alert  face/text]

If a second block is provide, it is used for the alternate
actions (right key):


    button "Click Here" [view/new layout [txt "action"]] [view/new layout 
    [txt "alt-action"]]


Use variables to modify the contents or state of other faces. For 
example, the slider will update the progress bar:

    slider 200x16 [p1/data: value show p1]
    p1: progress

!More action on actions needed...

===Show


After the state is changed for a user interface element, it must 
be re-drawn to be reflected on the user interface canvas.

Accomplish this with the show message.

    backtile polished
    across 
    toggle "Toggle State"  
            [   cybernetics?/data: not cybernetics?/data
                show cybernetics?]  

    return  label "Are you interested in cybernetics?" cybernetics?: 
    check 

One show command can be used for multiple user interface elements

        backtile polished orange
        across
        b1: check label "Red" return
        b2: check label "Green" return

        button 200 "Change State But No Refresh" [b1/data: not b1/data b2/data: 
        not b2/data] return
        button "Show" [show [b1 b2]]
===Hide

A user interface element can also be hidden.

        backtile polished orange
        across
        c1: check 
        hide-button: button "Hide" [hide c1] return
        show-button: button "Show" [show [c1 d2]]


The show-button action tries to show a user interface element 'd2' 
that does not exist.
REBOL/View ignores these.
===Invisible Faces


To make a button invisible when the view is opened, you can define 
an invisible button style

This approach sets the show? value to false when the user interface 
element is initialized.

    across

    style invisible-button button with [append init [show?: false]]
    late-shower: invisible-button "I'm Here" return
    return button 200 "Show Invisible Button" [show late-shower]
    
This works for the other visible user interface element.

===Focus

A user interface element can programmatically be given the focus.

    across backtile polished 
    button 200 "Set focus to Phone Field" [focus f2] 
    return label "Name: "   f1: field 100 
    return label "Phone: " f2: field 100 

    return button 200 "Remove focus from Phone Field" [unfocus f2] 
    return button 200 "Hide the Phone Field" [hide f2] return

---Focus Defect


!Note that the tab function shows a hidden field. I have assumed 
that this is a defect. If a field is hidden, the tab button should 
not make it visible. This has been previously sent to feedback.

===Radio Buttons


A radio button is used to make a choice between mutually exclusive 
values. Your preferred programming language is REBOL or C++ or PL/1 
or APL but it is only one of those.

            across backtile polished

            radio of 'programming-language pad 0x-4 label "REBOL" return

            radio of 'programming-language pad 0x-4 label "C++" return

            radio of 'programming-language pad 0x-4 label "PL/1" return

            radio of 'programming-language pad 0x-4 label "APL" return


To mix two groups of radio buttons on one screen, associate them 
with their groups using the "of 'word". In the above, the grouping 
is 'programming-language.

            across backtile polished

            radio of 'programming-language pad 0x-4 label "Language: REBOL" return

            radio of 'programming-language pad 0x-4 label "Language: C++" return

            radio of 'editor pad 0x-4 label "Editor: TextPad" return

            radio of 'editor pad 0x-4 label "Editor: Notepad" return


The padding in the above is needed to keep the label aligned with 
the radio button.

            across backtile polished orange

            radio of 'programming-language pad 0x-4 label "REBOL" return

            radio of 'programming-language          label "APL" return
            
            
            
            

===Radio Button Settings


A radio button is not very useful unless you can find out what its 
setting is and change that setting under program control.


            across backtile polished orange

            rebol-radio:    radio of 'programming-language  [programming-language: 
            'rebol] pad 0x-4 label "REBOL" return

            apl-radio:      radio of 'programming-language  [programming-language: 
            'apl]         label "APL" return
            button 200 "Toggle radio button" [

                    apl-radio/data: not rebol-radio/data: not rebol-radio/data
                    show [rebol-radio apl-radio]
            ]
            
===Check Box

---Purpose


A check box is used to allow user interface choices where the choices 
are not mutually exclusive.

        across backtile polished orange
        c1: check label "Likes animals" return
        c2: check label "Like Monkees" return
        c3: check label "Like The Animals"
        
---State


A check box is not much good if you can't get and set its state (on 
or off).

        across backtile polished orange
        c1: check label "Likes animals" return
        c2: check label "Like Monkees" return
        
    button "Set State" [
        c1/data: true 
        show c1
        c2/data: false
        show c2
    ]
 
 
===Sensor

---Purpose


A sensor is an invisible user interface element. Using a sensor only 
makes sense in a few instances. 


If you want a keycode action where there is no visible user interface 
element to link the action to then a sensor can be used.


This sensor code adds an Escape or Back or Enter action that will 
close the window. 

    sensor 1x1 keycode [#"^M" #" " #"^(back)" #"^(ESC)"] [unview]


Or if you want to make portions of an image 'hot' instead of putting 
buttons on top of the image, then a sensor will achieve this.

        across backtile polished orange

        txt "Click on the upper left section of the gray image to invoke 
        the sensor action"

        return animage: image 100x100 polished      ; here the image is just 
        the polished area

        at animage/offset sensor 50x50 [alert "You pushed over the sensor"]
        
===Displaying Script Values


If the script has a standard format headings, including custom ones, 
these can be used in the application by picking them from the system/script/header.

        backtile polished
        across banner "About"

        return text font-size 16    rejoin ["Title: "           form system/script/header/title]

        return text font-size 16  rejoin ["Originator: "    form system/script/header/author] 
              

        return text font-size 16  rejoin ["Modifier: "      form system/script/header/modifier]

        return text font-size 16  rejoin ["Version: "       form system/script/header/version]

        return text font-size 16  rejoin ["Updated: "       form system/script/header/date]
        return button "OK" [unview] 

===Toggle


A toggle button represents boolean state - either on or off. The 
button stays down until toggled again.
Colors and text can be paired for "on" and "off" state.

    toggle "Up" "Down" red blue

To set the state via program control, use:

        across backtile polished
        return t1: toggle "Up" "Down" red blue
        return button polished 204.0.0 100 "Toggle State" [
            t1/state: not t1/state
            show t1
        ]


===Rotary Buttons


Rotary buttons are a different sort of user interface device. They 
can cause some challenges because the state is what's showing so 
you have to blindly "toggle" to get to a state that you want.  But 
for quick and easy uses where the user is familiar with the options, 
they can be handy.  If you plan to use them for a long list of items 
such as shown  below, they might give you some usability concerns.


---Example

        across backtile polished
        rotary data ["First" "Second" "Third"]

---Setting State

        across backtile polished

        return r1: rotary data (my-options: ["First" "Second" "Third"])
        return button 200 "Change Rotary State" [
            r1/data: next r1/data
            if tail? r1/data [r1/data: head r1/data]
            show r1
        ]

---Example - Usability For Unfamiliar List Contents


The rotary button demonstrated here contains some information unfamiliar 
to most (Saturn's satellites). Use it to to set the state so that 
"Calypso" is set. Doable but without knowing the order each re-paint 
has to be checked to ensure that it is not "Calypso" before clicking 
again.  If you do click past the choice that you want, there is no 
back function so you have to cycle through again.

        return rotary data [

            "Pan" "Atlas" "Prometheus" "Pandora" "Epimetheus" "Janus" "Mimas" 
            "Enceladus" "Tethys" "Telesto" "Calypso" "Dione" "Helene" "Rhea" 
            "Titan" "Hyperion" "Iapetus" "Phoebe"        
        ]


===Arrows


REBOL/View supports arrows as simple user interface elements. Actions 
can be associated with them.



---Arrowheads And Actions

By default, the arrow is 20x20

    across size 200x100 
    backtile polished
    at 50x50 arrow left 
        [alert "You pressed the left arrow"] 

        [alert "You pushed the alternate button on the left arrow"] 
    at 70x30 arrow up
    at 90x50 arrow right [alert "You pressed the right arrow"]
    at 70x70 arrow down
    
---Very Sharp Arrows


And with a little work the arrows and boxes can be merged to look 
sharper. Here is a "sharp at both ends" arrow from the block diagram 
script by Carl:

    origin 0
    backcolor white
    at 0x0 box 40x40 white effect [arrow rotate 270]
    at 110x0 box 40x40 white effect [arrow rotate 90]
    at 24x10 box black 100x20
    
---Arrow Blend

So that shows you how to make an arrow blend into your background

    size 100x100
    across backdrop gray
    at 50x50 box 40x40 gray effect [arrow rotate 90]
    at 40x67 box 25x5 black
    
===LED

LEDs would be used to display state (on or off).  

Clicking the LED toggles its state and changes its color.

LEDs do not support alternate mouse button actions.

    across banner "Light Emitting Diode"
    return 

    l1: led 10x10 [alert "LED left mouse action"] label "Alert status"

    l2: led 10x10 [alert "LED left mouse action"] label "Network status"
    return button "Change state" [
        l1/data: not l1/data
        l2/data: not l2/data 
        show [l1 l2]        
    ]
    
===Box


---Boxing

Draw boxes of any heigth and width with the box style

    box "Large Box" 200x400 polished orange
    
---Boxes As Lines


If you make the box narrow enough or short enough it is a line (or 
a dot).

    across size 300x300 backtile polished
    at 50x0 box 3x100 gold
    at 0x50 b1: box 100x3 gold
    at 10x10 box 5x5 red
    
---Boxes Can Grow

    across size 300x300 backtile polished
    at 150x0 b1: box 100x3 gold
    return pad 0x100 button "Grow Down" [
        for i 3 300 1 [
            b1/size/y: 1 + b1/size/y
            wait 00:00:00.01
            show b1
        ]
    ]

    return pad 0x100 button "Back Up" [
        for i 300 3 -1 [
            b1/size/y: b1/size/y - 1
            wait 00:00:00.01
            show b1
        ]
    ]

You might even find a use for it.


---Grid Effect

Not sure of the use for this yet but here is what you can do:


 return box "Grid Lock" with [effect: [grid 20x20 8x8 4x3]] white 
 300x200
 

 return box "Grid Lock" with [effect: [grid 20x20 5x5 3x3]] white 
 - 80 300x200
 
===Frame

Earlier versions of REBOL VID supported frames in layouts such as
view layout [frame "This is the Bay" %bay.jpg]

These are no longer valid.

But frames can be put around some user interface devices:

    image 100x100 polished frame red
    
===List


A list is an iterated sub layout and takes a layout block that uses 
the Visual Interface Dialect. The styles in the layout will be repeated 
until there is no more room to fit them within the list dimensions.


---Why


A face can be iterated to create a number of virtual faces. For instance, 
when displaying a list of ten buttons, each of the buttons does not 
need to be created as a separate object. If the buttons only differ 
by a few facets (such as position, text, and action taken on selection), 
a model face can be created and iterated for its other position. 
This is useful when creating scrolling lists of files and other data 
sets that share the same appearance. 

---Supply


Supply provides the data to the list for an iterated face.

    do [cnt: 0
        list-collection: [aqua sky water]    
    ]
    backtile polished orange
    across
    list-displayed: list 100x72 [
        origin 0 space 0x0 across
        color-field: txt bold 80x24
    ] supply [
            if none? one-color: pick list-collection count [exit]
            face/text: do pick [one-color] index

    ]

    return txt gold 180 "OK ... but not too useful"


---Supply Columns

Maybe adding some more columns would be better.

Here I'll add a column of buttons that display the color name
and a column of text strings in italic.

    do [
        cnt: 0
        list-collection: [aqua sky water gold silver coffee]    
    ]
    backtile polished orange
        across
        list-displayed: list 300x200 [
            origin 0 space 0x0 across
            color-field: txt bold 80x24
            color-button: button 80x24
            pad 5x1
            txt 100 italic
        ] supply [

                if none? one-color: pick list-collection count [exit]
                face/text: do pick [
                    [one-color]
                    [to-string one-color]
                    [rejoin ["  " to-string one-color]]
                    ] index 
    ]
    

    return txt gold 300 {A bit more interesting but the last row repeats 
    to fill the list size. Some of the other VID components will automatically 
    stretch to fit the size needed (such as this txt field) but the list 
    does not behave that way.  You have to make the list size fit its 
    data or make it smaller and add a vertical scroll capability. That 
    is shown a little later on.}

===List With Supplied Data

This example is to show adding action to the list
and adds a horizontal line between the rows.


    do [
        cnt: 0
        list-collection: [aqua sky water gold silver coffee]    
    ]
    backtile polished orange
        across

        list-displayed: list water edge [size: 6x6 color: silver]  350x96 
        [  
            origin 0 space 0x0 across

            color-field: txt 60 [alert rejoin ["You pressed the " face/text " 
            text field"]]
            pad 45x0            

            color-button: button 80 [alert rejoin ["You pressed the " face/text 
            " button"]]
            pad 5x0
            txt 120 italic

            return box 350x1 white      ; this causes a horizontal line to appear 
            between each row

        ] supply [

                if none? one-color: pick list-collection count [exit]
                face/text: do pick [
                    [one-color]
                    [to-string one-color]
                    [rejoin ["  " to-string one-color]]
                    ] index 
    ]


===Supply List With Scroll

This example shows a supplied list with a scroll capability.
More colors are added to demonstrate scrolling.

Note that this is a verbose list of code where I added comments
for my understanding of how the scroll was linked to the list.
The same effect can be accomplished with fewer lines of code.
    

    do [    ; first this do block creates the data definitions needed.
        slider-position-clicked:  0
        count: 0    
        x: 450
        y: 300

        row-y: 16           ; the row height includes the data plus any separator 
        lines 

        list-size: to-pair reduce [x y]     ; this is the size of the display 
        list  
        separator-size: to-pair reduce [x 1]
        slider-size: to-pair reduce [24 y ]
        list-collection: [

            aqua           bar-color   base-color     beige         black    
                  blue           brick          brown      

        button-color   coal        coffee         crimson       cyan     
              forest         gold           gray       

        green          ivory       khaki          leaf          linen    
              magenta        main-color     maroon     

        mint           navy        oldrab         olive         orange   
              over-color     papaya         pewter         

            pink           purple      rebolor        red           sienna   
                  silver         sky            snow

        tan            teal        violet         water         wheat    
              white          yellow        
        ]    
        
        supply-style: stylize [

                button-fixed: button left coal to-pair reduce [80 row-y]        ; 
                these keep the row elements the same height

                text-fixed: txt to-pair reduce [160 row-y]          
        ]
        
        data-size: length? list-collection  
    ]
    

    backtile polished orange                        ; this section layouts 
    out the list
        
        across

        list-position: at                                   ; the position 
        is captured here in order to later put the slider beside it
        list-displayed: list linen 
            edge [size: 6x6 color: tan]  list-size [  
            origin 0 space 0x0 across
            styles supply-style

            text-fixed [alert rejoin ["You pressed the " face/text " text field"]]

            button-fixed [alert rejoin ["You pressed the " face/text " button"]]
            pad 5x0 

            text-fixed 80 italic [alert rejoin ["You pressed the italic " face/text 
            " text field"]]

            return box separator-size gray      ; this causes a horizontal line 
            to appear between each row

        ] supply [
                count: count + slider-position-clicked  

                if none? one-color: pick list-collection count [exit]
        face/text: 
            either count > (1 + data-size) 
            [""]
            [
                             do pick [

                                    [one-color]                                                      
                                           ; this is supplied to the first txt field (text-fixed)

                                    [to-string one-color]                                           ; 
                                    this is supplied to the button (button-fixed)

                                    [rejoin ["  " to-string one-color " "]]     ; this value is supplied 
                                    to the last text-fixed field
                            ] index 
                    ]
        ]


        ; now add a slider to the side of the list



        at list-position + (list-size * 1x0)                             
           ; this finds the top right border of the list widget
        vertical-slider: slider slider-size to-integer y / row-y
        [

                    slider-position-clicked: vertical-slider/data   ; the slider has 
                    to be bound to the size of the list                

                        * ((1 + data-size) - ((y / (1 + row-y))))       ; including the row 
                        height
                    if slider-position-clicked <> count [
                        count: slider-position-clicked 
                        show list-displayed
                    ]
                ]


===Slider


A slider is interactive user interface element. The data of a slider 
varies from 0 to 1.

    backtile polished   orange across
    slider-1: slider 200x40 
    return button 200 "Move first slider to 50%" [
        slider-1/data: .5 
        show slider-1
    ]

    return txt 200 "The second slider in this example is initialized 
    to the 80% mark."  
    return slider 200x40 with [append init [data: .8]]
    
===Progress Indicator


The progress-1 face in this example is a progress indicator. Because 
it is only displaying information, it is non-interactive i.e. you 
can not change its value by dragging its edges.  The alternate button 
is not supported on a progress indicator.

    backtile polished   orange across
    slider 200x40 [
        progress-1/data: value 
        field-1/text: join (to-integer (100 * value)) " %"
        show [progress-1 field-1]
    ] 
    return progress-1: progress
    return field-1: field
===Panels 


Panels are used to create sub-panes that can be more easily managed 
by grouping

the user interface devices on a panel. The first example below shows 
how to use panels for layout alignment. By creating a panel definition, 
all of the components defined within it are aligned relative to its 
origin.

    across backtile polished brick
    tabs 50
    return panel-1: panel 250x120 [
        backtile polished
        across
        return button water 200 "Button A"
        return button aqua  200 "Button B"
        return button sky   200 "Button C" 
    ]


    at panel-1/offset + panel-1/size panel 60x90 [  ; start at the bottom 
    right corner of panel-1
        backtile polished
        across
        return button tan       20 "1"
        return button coffee    20 "2"
    ]
    
---Multiple SubPanels example


This example from the REBOL html documentation shows how to easily 
hide and show sections of a user interface by displaying them on 
the face area of a box.  


        do [                                ; define two panels
            panel1: layout [
                    origin 8x8
                    h2 "Panel 1"
                    field "Field 1"
                    field "Field 2"
                    button "The Answer" [alert "I know nothing."]
            ]


            panel2: layout [
                origin 8x8
                    h2 "Panel 2"
                    across
                    txt "X:"
                    slider 150x16
                    return
                    txt "Y:"
                    slider 150x16
                    return
                    check [panel2/color: maroon  show panel2]
                    txt "Don't click this"
                    return 
                    check [panel2/color: silver  show panel2]
                    txt "Click this" 
                    return
                ]

                panel1/offset: 0x0
                panel2/offset: 0x0
        ]


        vh2 "Subpanel Examples"     ; now demonstrate panel use
        guide
        pad 20
        button "Panel 1" [panels/pane: panel1  show panels]
        button "Panel 2" [panels/pane: panel2  show panels]
        button "Quit" [unview]
        return
        box 2x140 maroon
        return
        panels: box 220x140
        do [panels/pane: panel1]
        
===Simple Default Style Override


The style's default look can be overriden easily with one line of 
code. 


For example, to make the default button size 200x200 with a water 
color, use

    style button button 200x200 water
    button "Big Blue Button" [unview]

To make the toggle some different default colors:

    style toggle toggle crimson sky
    toggle "Up" "Down"


Note that these stay in effect until they are overridden so if you 
use the default values, exercise some care unless you meant to do 
that. 



===Image Maker


An option used by Carl in some of his programs is to let View create 
specific icons so that you have portability and more control of look 
of the image then if you referenced an external file such as gif 
that was a bullet display. Here's how to do that:

    do [    
        make-image: func [xy wh eff] [
            eff: layout [
                size 20x20 at xy
                box wh effect eff
            ]
        eff/color: rebolor
        to-image eff
        ]


        dot: make-image 6x5 9x9 [gradient 1x1 255.0.0 0.0.0 oval key 0.0.0]

        dot-big: make-image 8x7 12x12 [gradient 1x1 255.0.0 0.0.0 oval key 
        0.0.0]
        arr: make-image 3x3 14x14 [arrow 0.0.127 rotate 90]
        ard: make-image 3x3 14x14 [arrow 0.0.127 rotate 180]    

    ]   ; end of "do" - it is needed here because easyvid approach is 
    expecting vid dialect commands

    banner "Presentation Points"
    size 400x300 across

    style label label gold     ; make a label's text be a different color 
    than the default
    return image dot label "This is bullet point number 1" 
    return image dot label "This is bullet point number 2"
    return image arr label "This is arrow point number 1"

    return image ard label "This is an arrow making a different point"

    return image dot-big pad 0x4 area 300x80 wrap "And because these 
    arrows and dots are images, action can be added to them to make them 
    'hot' with mouse actions including 'over'."
    
===Needs Some Work

!More to come.  These still need to be covered in this
tutorial:

    text-list data [
        icon
    ]
    
===Digital Clock

    origin 0
    banner "00:00:00" rate 1 effect [gradient 0x1 0.0.150 0.0.50]

        feel [engage: func [face act evt] [face/text: now/time  show face]]


 


===REBOL Logo

 image %rebo-logo.gif [unview]

===Paint Drops

REBOL one liner by Vincent Ecuyer


 b: box rate 9 effect[draw[pen(random snow)circle(random 99x99)2]blur]box 
 1x1 rate 9 effect[draw[(b/image: to-image b)]]
 
===eMailer

One line emailer by Doc Kimbel

Assumes you have set up your email in set-user



 e: field "Email" s: field "Subject" m: area "Body" btn "Send"[send/subject 
 to-email e/text m/text s/text alert "ok"]
 
===Hello World

 text "Hello World!" button "Close" [unview]
===Three Buttons

 button "Yes" button "Maybe" button "No"

===View Web Text

 text 800x600 read http://www.rebol.com
 
===View Image

 image %palms.jpg
 
===View Image and File Name


Here a do block is used to initialize the file variable within the 
layout code.

 do [file: %palms.jpg]
 image file  text form file
 
 
===View Image behind File Name


Here a do block is used to initialize the file variable within the 
layout code.

 do [file: %palms.jpg]

 image file form file
 
 
===Buttons From Images

    backdrop 40.70.140
    stat: text bold "Click a Button" 100x20 240.140.40 center
    button "Bay Test"  %bay.jpg 100x100 [
        stat/text: "Upper" 
        show stat
    ]
    button "Blue Test" %bay.jpg 100x100 10.30.180 [
        stat/text: "Lower" 
        show stat
    ]
===View List


 list blue 320x200 [across text white 200 text white 100] data [
    ["John" 100] 
    ["Joe" 200] 
    ["Martin" 300]
 ]
===Movie Credits



    backdrop %bay.jpg effect [fit]

    text center bold 240x30 "REBOL, The Movie" yellow font [size: 16]
    credits: text {

 Edit This File 

 To Add Your Own Credits 
 

 It is very simple to do. 

 Only takes a minute. 

 Only REBOL Makes It Possible...

 } white bold center 240x180 rate 30 para [origin: 0x+100]
        feel [engage: func [f a e] [

            if a = 'time [f/para/origin: f/para/origin - 0x1 show f]
        ]
    ]



===Fire Demo

    box 150x150 with [
        edge: none
        img: image: make image! 150x150
        rate: 20
        text: "FIREBOLEK"
        font: make font [size: 24 color: 255.125.0]

        basic: [draw [image make pair! reduce [(random 3)  - 2 -1] img]]
        effects: reduce [
            append copy basic [blur luma -10]
            append copy basic [sharpen luma -10 blur]
            append copy basic [contrast 10 blur luma -5]        
        ]
        effect: first effects
        feel: make feel [
            engage: func [f a e][
                switch a [

                    down [f/effects: next f/effects if tail? f/effects [f/effects: head 
                    f/effects] f/effect: first f/effects show f]

                    time [show f repeat i f/size/x - 4 [poke f/image (f/size/x * f/size/y) 
                    - i - 2 (random 255.0.0 + random 0.127.0) * 3] f/img: to-image f] 
                           
                ]       
            ]
        ]
    ]
    text 150 {classical fire demo for REBOL^/
 press on fire to see other effects.^/   
 Written by ReBolek, 2001 in 15 mins.^/
 We need new category on Assembly:^/
 less-than-kb-demo ;-)} with [font: make font  [size: 9]]
===Bezier 

Oldes Bezier Line Demo

See script library for %bezier-curve.r

Uses functions and data initialized at script startup

The end points are draggable to change the curve!!!!


Here a do block is used to allow executable lines for initialization 
purposes.

 do [

    draw-beziere-curve: has [result pp x0 x1 x2 x3 y0 y1 y2 y3 cx bx 
    ax cy by ay t tx ty s] [
    result: make block! 120
    pp: p0/size/x / 2
    x0: p0/offset/x + pp
    y0: p0/offset/y + pp
    x1: p1/offset/x + pp
    y1: p1/offset/y + pp
    x2: p2/offset/x + pp
    y2: p2/offset/y + pp 
    x3: p3/offset/x + pp
    y3: p3/offset/y + pp

    insert result compose [
        pen 155.0.0
        line (p0/offset + pp) (p1/offset + pp)
        line (p2/offset + pp) (p3/offset + pp)
        pen 255.255.255 line (p0/offset + pp)
    ]    
    cx: 3 * (x1 - x0)
    bx: 3 * (x2 - x1) - cx
    ax: x3 - x0 - cx - bx
    cy: 3 * (y1 - y0)
    by: 3 * (y2 - y1) - cy
    ay: y3 - y0 - cy - by
    
    t: s: 0.01 ;this value sets quality of the curve
    
    while [t <= 1][
        tx: to integer! (

                (ax * (t * t * t)) + (bx * (t * t)) + (cx * t) + .5
            ) + x0
        ty: to integer! (

                (ay * (t * t * t)) + (by * (t * t)) + (cy * t) + .5
            ) + y0

        t: t + s
        insert tail result to pair! reduce [tx ty]
    ]
    return result
 ]


 click?: false
 mouse-pos: 0x0


 ]

    origin 0

    bkg: box black 400x400 with [effect: reduce ['draw make block! 120]]
    style point box 10x10 with [

        effect: [draw [pen 0.255.0 fill-pen 0.200.0 circle 4x4 4]]
        changes: [offset]
        feel: make feel [
            engage: func [f a e][
                if a = 'down [click?: on mouse-pos: e/offset]
                if a = 'up   [click?: off]
                if find [over away] a [
                    if click? [
                        f/offset: f/offset + e/offset - mouse-pos
                        bkg/effect/2: draw-beziere-curve
                        show [bkg f]
                    ]
                ]
            ]
        ]
    ]
    at 300x200 p0: point
    at 200x100 p1: point
    at 200x300 p2: point
    at 100x200 p3: point
    do [bkg/effect/2: draw-beziere-curve]
                   
===Buttons Galore

Buttons galore from the library script %buttons.r


Here a do block is used to execute the initialization needed within 
the layout block.



    do [
        group: ["rotary" "test" "button"]
    ]

    origin 20x10
    backdrop effect [gradient 0x1 100.20.0]

    vh1 "52 Button Click-up - Each with a different click effect..."

    vtext bold "Here is a small sampling of the thousands of button effects 
    you can create. (This is 78 lines of code.)"
    at 20x80 guide
    button "simple"
    button form now/date
    button "colored" 100.0.0
    button "text colored" font [colors: [255.80.80 80.200.80]]
    button with [texts: ["up text" "down text"]]
    button "bi-colored" colors [0.150.100 150.20.20]

    button with [texts: ["up color" "down color"] colors: [0.150.100 
    150.20.20]]
    button "image" pic
    button "color image" pic 200.100.50

    button "flip color" pic with [effects: [[fit colorize 50.50.200][fit 
    colorize 200.50.50]]]
    button "blink" with [rate: 2 colors: [160.40.40 40.160.40]]
    return

    button "multiply" pic with [effects: [[fit][fit multiply 128.80.60]]]
    button "brighten" pic with [effects: [[fit][fit luma 80]]]

    button "contrast" pic with [effects: [[fit][fit contrast 80]]]
    button "horiz flip" pic with [effects: [[fit][fit flip 1x0]]]

    button "vert reflect" pic with [effects: [[fit][fit reflect 0x1]]]
    button "invert" pic with [effects: [[fit][fit invert]]]

    button "vert grad" with [effects: [[gradient 0x1 0.0.0 0.200.0] [gradient 
    0x1 0.200.0 0.0.0]]]

    button "horiz grad" with [effects: [[gradient 1x0 200.0.0 200.200.200][gradient 
    1x0 200.200.200 200.0.0]]]

    button "both grad" with [effects: [[gradient 1x0 140.0.0 40.40.200] 
    [gradient 0x1 40.40.200 140.0.0]]]

    button "blink grad" with [rate: 4 effects: [[gradient 1x0 0.0.0 0.0.200] 
    [gradient 1x0 0.0.200 0.0.0]]]

    button "blink flip" pic with [rate: 8 effects: [[fit][fit flip 0x1]]]
    return
    button "big dull button with several lines" 100x80 0.0.100

    button "dual color" pic 50.50.100 100.50.50 100x80 with [edge: [color: 
    80.80.80]]

    button "big edge" pic 100x80 with [edge: [size: 5x5 color: 80.80.80] 
    effects: [[fit colorize 50.100.50][fit]]]

    button "oval reflect" pic 50.100.50 100x80 with [effect: [fit reflect 
    1x0 oval]]
    return

    button "text on top" pic 100x80 with [font: [valign: 'top] effects: 
    [[fit gradcol 1x1 200.0.0 0.0.200] [fit gradcol -1x-1 200.0.0 0.0.200]]]

    button "text on bottom" pic 100x80 50.50.100 with [font: [valign: 
    'bottom] effects: [[fit][fit invert]]]

    button "big text font" pic 100x80 with [font: [size: 24] effects: 
    [[fit multiply 50.100.200][fit]]]

    button "cross flip" pic 50.100.50 100x80 with [effect: [fit flip 
    0x1 reflect 0x1 cross]]
    return
    toggle "toggle"
    toggle "toggle red" 100.0.0 
    toggle "toggle up" "toggle down"
    toggle "toggle colored" 0.150.100 150.20.20
    toggle "up color" "down color" 0.150.100 150.20.20

    toggle "toggle multiply" pic with [effects: [[fit][fit multiply 128.80.60]]]

    toggle "toggle contrast" pic with [effects: [[fit][fit contrast 80]]]
    toggle "toggle cross" pic with [effects: [[fit][fit cross]]]

    toggle "toggle v-grad" with [effects: [[gradient 0x1 0.0.0 0.200.0] 
    [gradient 0x1 0.200.0 0.0.0]]]

    toggle "toggle h-grad" with [effects: [[gradient 1x0 200.0.0 200.200.200][gradient 
    1x0 200.200.200 200.0.0]]]

    toggle "toggle both" with [effects: [[gradient 1x0 140.0.0 40.40.200] 
    [gradient 0x1 40.40.200 140.0.0]]]
    return
    rotary data group
    rotary data reduce [now/date now/time]
    rotary data group 100.0.0 0.100.0 0.0.100

    rotary data group with [font: [colors: [255.80.80 80.200.80]]]
    rotary data group with [colors: [0.150.100 150.20.20]]
    rotary data group pic
    rotary data group pic 200.100.50

    rotary data group pic with [effects: [[fit colorize 50.50.200][fit 
    colorize 200.50.50]]]

    rotary data group with [effects: [[gradient 0x1 0.0.0 0.200.0] [gradient 
    0x1 0.200.0 0.0.0]]]

    rotary data group with [effects: [[gradient 1x0 200.0.0 200.200.200][gradient 
    1x0 200.200.200 200.0.0]]]

    rotary data group with [effects: [[gradient 1x0 140.0.0 40.40.200] 
    [gradient 0x1 40.40.200 140.0.0]]]
===Paint Program


This section is a clip of the layout portion of Frank Sievertsen's 
remarkable paint program. Open this example to enable a quick link 
to the real source:


 button "Browse Source" [browse http://www.reboltech.com/library/html/paint.html]
 button "Close" [unview]


In the example below, a DO block is used to execute initialize code.

 do [

    color: fill-color: start: draw-image: draw-pos: tmp: none
    type: 'box
    undos: [] redos: []
    draw: func [offset /local tmp] [
        compose [
            pen (color/color) fill-pen (fill-color/color)
            (type) (start) (either type = 'circle [
                tmp: offset - start
                to-integer square-root add tmp/x ** 2 tmp/y ** 2
            ] [offset])
        ]
    ]
 ]
 
        backdrop effect compose [gradient 1x1 (sky) (water)]
        across
        draw-image: image white 300x300 effect [draw []]
        feel [engage: func [face action event] [
            if all [type start] [
                if find [over away] action [
                    append clear draw-pos draw event/offset
                    show face
                ]
                if action = 'up [
                    append/only undos draw-pos
                    draw-pos: tail draw-pos
                    start: none
                ]
            ]
            if all [type action = 'down] [
                start: event/offset
            ]
        ]]
        do [draw-pos: draw-image/effect/draw]
        guide
        style text text [
            tmp: first back find face/parent-face/pane face
            tmp/feel/engage tmp 'down none
            tmp/feel/engage tmp 'up none
        ]
        label "Tool:" return
        radio [type: 'line] text "Line"
        return
        radio [type: 'box] on text "Box"
        return
        radio [type: 'circle] text "Circle"
        return
        style color-box box 15x15 [

            face/color: either face/color [request-color/color face/color] [request-color]
        ] ibevel
        color: color-box 0.0.0 text "Pen"
        return
        fill-color: color-box text "Fill-pen"
        return
        button "Undo" [if not empty? undos [
            append/only redos copy last undos
            draw-pos: clear last undos
            remove back tail undos
            show draw-image
        ]]
        return
        button "Redo" [if not empty? redos [
            append/only undos draw-pos
            draw-pos: insert draw-pos last redos
            remove back tail redos
            show draw-image
        ]]
===Font Lab

Carl's Font lab



Here a do block is used to initialize some values needed in the layout

 do [

    change-styles: func [style start facet subfacet value /local v][
    start: find style/pane start
    foreach f start [
        f: in f facet
        if subfacet <> 'none [f: in get f subfacet]
        either block? value [

            if not block? get f [set f either none? get f [copy []][reduce [get 
            f]]]

            either v: find get f value [remove v][head insert get f value]
        ][set f value]
    ]
    show style
 ]

 chg: func ['facet 'subfacet value] [
    change-styles external-view norm-start facet subfacet value
 ]
 shad: does [chg font shadow sdir * to-integer sl2/data * 16]
 sdir: 1x1
 sz: 180x40
 sx2: sz/x / 2 
 ]



    style tgl toggle 60
    style lab vtext bold
    backcolor rebolor
    space 0x5
    across 

    p: choice 180 "Sans-Serif Style" "Serif Style" "Fixed Width Style" 

        [chg font name pick reduce [font-sans-serif font-serif font-fixed] 
        index? p/data]
        return
    tgl "Bold" [chg font style [bold]]
    tgl "Italic" italic [chg font style [italic]]
    tgl "Lined" underline [chg font style [underline]]
    return
    tgl "Left" of 'tg1 [chg font align 'left]
    tgl "Center" of 'tg1 [chg font align 'center]
    tgl "Right" of 'tg1 [chg font align 'right]
    return
    tgl "Top" of 'tg2 [chg font valign 'top]
    tgl "Middle" of 'tg2 [chg font valign 'middle]
    tgl "Bottom" of 'tg2 [chg font valign 'bottom]
    return
    lab "Size:" 60x20 font []

    sl: slider 120x20 [chg font size max 8 to-integer sl/data * 40] 
     with [append init [data: .5]]
    
    return
    lab "Space:" 60x20 font []

    sl1: slider 120x20 [chg font space (1x0 * to-integer sl1/data * 20) 
    - 5x0]
    return
    lab "Shadow:" 60x20 font []
    sl2: slider 120x20 [shad]  with [append init [data: .5]]
    return
    lab "Shad Dir:" 60x20
    arrow left  [sdir: sdir * 0x1 + -1x0 shad] pad 6
    arrow right [sdir: sdir * 0x1 + 1x0 shad]  pad 6
    arrow up    [sdir: sdir * 1x0 + 0x-1 shad] pad 6
    arrow down  [sdir: sdir * 1x0 + 0x1 shad]  pad 6
    return
    button sx2 "Text Color" [chg font color request-color]
    button sx2 "Area Color" [chg color none request-color]
    return

    button sx2 "Help" [alert "Click the controls on the left to change 
    text on the right."]
    button sx2 "Close" #"^Q" [unview]
    below
    at p/offset + (p/size * 1x0) + 10x0
    norm-start:
    Title "Title" sz
    h1 "Heading 1" sz
    h2 "Heading 2" sz
    h3 "Heading 3" sz
    h4 "Heading 4" sz
    h5 "Heading 5" sz
    at norm-start/offset + (norm-start/size * 1x0) + 10x0
    banner "Banner" sz
    vh1 "Video Heading 1" sz
    vh2 "Video Heading 2" sz
    vh3 "Video Heading 3" sz
    vtext "Video Text" sz
    text "Document Text" sz
    

===Windows Clipboard


---Cut or Copy to Clipboard


Normal Windows cut and copy commands are supported e.g. on a field, 
contents can be copied to the clipboard. Programmatic access is also 
supported for text contents.

    across 
    label "Entry field: "
    return input-field: field 200 "Enter your text here"

    return button 200 "Copy Entry field data to clipboard" [write clipboard:// 
    input-field/text]

    return button 200 "Show Clipboard Contents" [alert read clipboard://] 


---Clearing The Clipboard


    across 
    button 200 "Clear The Clipboard" [write clipboard:// ""]

    return button 200 "Show Clipboard Contents" [alert read clipboard://] 



---Paste from Clipboard


Normal Windows paste commands are supported e.g. on a field, contents 
can be pasted. Programmatic access is also supported for text contents.

    across 

    button 200 "Show Clipboard Contents" [alert read clipboard://] 
===Requesters


REBOL View supports an assortment of requesters. 


The results of the request-* code are returned as its value e.g. 
chosen-date: request-date


---Request Yes | No | Cancel


Provides the user the capability to pick from choices "Yes" | "No" 
| "Cancel"

The result is "True" | "False" | none

    do [user-response: none]

    button "Simple Request" 200 [user-response: request "Do you want 
    to abandon your input so far?"]
    button "View User Response" 200 [alert form user-response]
    

---Pick A Color

    do [chosen-color: gold] 
    button "Pick Color" 200 [chosen-color: request-color]
    button "View Chosen Color" 200 [alert form chosen-color]



---Pick An Answer

The request allows a descriptive value then 1, 2, or 3 options.


    button "Format" 100 [request ["Your message goes here. It will wrap 
    if it is very very long." "Choice 1" "Choice 2" "Choice 3"]]
    

    button "Example 1" 100 [request ["Pick The Color of Your New Model 
    T" "Black"]]
    

    button "Example 2" 100 [request ["Pick one country" "England" "France"]]


    button "Example 3" 100 [request ["Run Extract Script?" "Yes" "No" 
    "Cancel"]]


---Pick A Date

    do [chosen-date: 01-Jun-1990]
    button "Pick Date" 200 [chosen-date: request-date]
    button "See Chosen Date" 200 [alert form chosen-date]

---Get A LogonID and Password

    do [credentials: none]
    button "Get Credentials" 200 [credentials: request-pass]
    button "View Credentials" 200 [
        view/new layout [
            size 200x200 backtile polished orange 
            across banner "Credentials" 
            return label "LogonID:  " txt pick credentials 1
            return label "Password: " txt pick credentials 2
        ]
    ]


---Pick A File


Format: REQUEST-FILE /title title-line button-text /file name /filter 
filt /keep    

        do [filter-block: ["*.gif" "*.jpg" "*.png" "*.bmp"]]

        button "Pick Any File" 300 [request-file "Select"]      

        button "Pick With A Title" 300 [request-file/title "Pick The Data 
        File to Process" "OK"]

        button "Change the Action Button Name" 300 [request-file/title "Pick 
        The Data File to Process" "OK"]        

        button "Keep Results" 300 [request-file/title/keep "Previous Select 
        On This Button Is Kept" "OK"]

        button "Filter Files" 300 [request-file/title/filter "Pick An Image 
        File" "OK" filter-block]    



---Request Text Input

Format: REQUEST-TEXT /offset xy /title title-text /default str
    

    button "Request Text Input - all default parameters" 300 [request-text]

    button "Request Text Input - with offset to window" 300 [request-text/offset 
    40x40]

    button "Request Text Input - with title" 300 [request-text/title 
    "Input your question"]

    button "Request Text Input - with default" 300 [request-text/default 
    "Key your question here"]

    button "Request Text Input - with all parameters" 300 [request-text/offset/title/default 
    100x100 "Input your question" "Key your question here"]



---Request Download from Net


Request a file download from the net. Show progress. Return none 
on error.

Format: REQUEST-DOWNLOAD url /to local-file

    backtile polished orange    

    button "Request File Download To local REBOL Cache" 300 [request-download 
    http://www.rebol.com/index.html]

    button "Request File Download To This Directory" 300 [request-download/to 
    http://www.rebol.com/index.htmlnone]

    button "Request File Download To Specific File" 300 [request-download/to 
    http://www.rebol.com/index.html%/c/temp.html]

===Message Box


    button "Format" 100 [request ["Your message goes here. It will wrap 
    if it is very very long and tedious." "Close"]] 
    button "Example" 100 [request ["You done good!" "OK"]]



---Confirmation

    button "Exit" 100 [
        request/confirm "Do you want to quit without saving?" []
    ]
    

===Calling the Editor

The REBOL editor is now callable with the editor function

    backtile polished
    button 300 "Create a test file and edit it" [
        write %temp.txt "This is a test file"
        editor %temp.txt
    ] frame 204.0.0 
    

===Calling Windows

With View/Pro the calling of executables is supported.

Here are two simple examples that will work if you have View/Pro 
on a platform where a notepad and calc are avaiable.

    across backtile size 200x200
    return button "Notepad" [call ["notepad.exe"]]
    return button "Calculator" [call ["calc.exe"]]


===Window Options


Note that these are options which are ignored by the easyvid.r code 
that displays them in this tutorial.
Copy the code out and run it standalone in REBOL/View.

---Block Options: No Border and No Title

    view/options layout [
        size 200x200 
        banner "Window Options" 
        button "Close" [unview]
        ] [
            no-border
            no-title
        ]


---Word Option: No Title


Note that the results of this are surprising if you run it from within 
a script that has a title option. It is displayed near location 0x0 
of the resulting window instead of in the window frame that has been 
suppressed. 

    view/options layout [
        size 200x200 
        banner "Window Options" 
        button "Close" [unview]
        ] 'no-title

===REBOL/View Notifiers


REBOL/View supports simple notifiers to send messages to a user interface


---Alert

    button 220 polished "Send alert message" [
        alert "This causes a dialogue box to popup"
    ]





---Flash

Flash is provided to provide a message and keep on processing.

    across size 200x200
    return button 150 "Create Flash Message" [flash "Testing"]
    return button 150 "Unview Flash" [unview]



---Inform

    inform layout  [
        backtile polished sky 

        across text font-size 16 bold underline red "Action complete!" 
        return button "OK"  [unview]]

---Popup

REBOL supports popups  (see note below before running!)

        across size 200x200 
        button "Show Popup" [
            show-popup popup-layout: layout [
                    across size 200x200 
                    backtile polished
                    banner "The Popup Worked" 
                    return button "Unview" [unview]
                ]
        ]
        return button "Hide Popup" [unview/only popup-layout]

I have had some difficulties (process lockup) when using

these popups so just use view layout [...] and skip the popup part.

===Diagram Example


Carl has created some diagrams in REBOL using styles to make an architecture 
diagram.

This is a slightly modified version.


Here again a DO block precedes the layout code for non-layout initiatiation 
... here the definition of a function.

Why make a diagram this way?


1. One reason is that it can be interactive ... the sections are 
all "hot" with a few lines of code.  Here they pop up REBOL Dialogs 
but they could do anything that can be coded even something as simple 
as launching a browser on a different URL for each diagram component. 
 The "Compositor" box demonstrates this by launching your browser 
on the REBOL.com site.


2. Very small footprint size compared to other presentation source 
formats.




 do [
        information: func [info [string!]][
        request/ok reform [ info]
    ]
 ]



    style bx box 255.255.255 0.0.0 font-size 11 font [color: 0.0.0 shadow: 
    0x0] edge [size: 5x2] 
        [request/ok reform ["No information on" face/text]] 

    style bb box bold left top para [origin: 6x10] edge [size: 2x2]
        [request/ok reform ["No information on" face/text]]
    backcolor silver + 30
    at 15x15 h1 486 left "Arch Structure" 
    at 15x50    bb "Client" 506x436 160.80.80 [

        information "Any client machine e.g. branch or Call Centre"]

    at 25x252   bb "Mid-Tier" 486x68 effect [gradient 1x1 169.91.155 
    80.45.75]

    at 25x152   bb "UI" 486x96    effect [gradient 1x1 38.156.82 19.78.41]

    at 25x324   bb "Servers" 486x151   effect [gradient 1x1 103.96.200 
    50.45.100] [

        information "Mid-tiers servers with XYZ relational database server" 
                                                                         
              
    ]

    at 130x216  bx "Compositor" 182x24 bold [browse http://www.rebol.com]

    at 130x60   bx "Browser" 120x24 [information "Branch standard browser"]

    at 130x188  bx "Sound" 182x24 bold [information "Sound services"]
    at 255x60   bx "Win32" 120x24 [information "Win32 App"]

===Column Images


Creates a layout looking (a little) like columns. It uses a gradient 
effect going from darker to lighter

 do [
     column: make image! layout [

            backdrop effect [gradient 1x0 20.20.20 250.240.230 luma 60]
        ]

    column-size: 50x420

    area-size: 400x420  ; height should be the same as column-size
 ]
 backtile polished tan
   across 
   image column-size  column 
   pad -10x0        ; this brings the default VID spacing back
   area wrap area-size  

   edge none        ; take the edge off of area so that it more closely 
   blends 
   shadow 2x2

   pad -10x0 image column-size column  ; if you want a right column

===Tree View of Directory

This is Didier's tree view %request-dir.r


In this sample, you must be online because the code is accessed on 
the Rebol script server

 do [do http://www.rebol.org/library/scripts/request-dir.r
     request-dir
 ]


Note that:

* the script is read from the script library but runs locally

* it is showing the files in your directories


===The emailer Function


The function for emailing has appeared in Jan-2004 on the rebol list.


It is a simple idea ... to create a standard emailer by invoking 
a function emailer. This window will show the source:

  text wrap 400x300 mold get 'emailer

And it is simple to run:

    across size 200x200
    return button 150 "Run emailer" [emailer]


But on my machine there is again a problem - the emailer locks up 
REBOL/View.

Recommendation:

* if it works use it if you like


* use Doc Kimbel's one liner (works for me). Assumes you have set 
up your email in set-user



 e: field "Email" s: field "Subject" m: area "Body" btn "Send"[send/subject 
 to-email e/text m/text s/text alert "ok"]



* better yet, make your own... if the code for the basic is 1 line, 
then a custom version is not far away. Here's an example that allows 
selection of your frequent contacts (entered in the names-addresses 
series) and keeps a journal of email that you have sent (using this 
code) in file email-journal.txt.  Assumes you have setup your user 
profile correctly to allow sending of email.


 do [

  names-addresses: [
    "Contact 1"         [contact1-:-no-such-address-:-com]
    "Contact 2"         [contact2-:-no-such-address-:-com]
    "Contact 3"         [contact3-:-no-such-address-:-com]
  ]

  names: copy []
  foreach [name address] names-addresses [append names name]


  journal?: false  ; set to true if want to journalize sent email
 ]

    e: rotary 200 data sort names
    s: field "Subject" 
    m: area 500x400 wrap "Body" 
    btn "Send"[

        send/subject who-to: select names-addresses e/text m/text s/text 
        alert join "Sent email to: " form who-to
        
        if journal? [
            write/append %email-journal.txt rejoin [
                "[ When-sent: " now/precise 
                " To: " who-to
                " Subject: {" s/text
                "} Message: {" m/text "} ] "
                newline
            ]
        ]
    ]
    btn "Quit" [unview]



It won't take much to change this from the rotary used to a text 
list allowing multiple selections.





===Some More email


Earlier there have been a few examples of sending email. Here are 
a few more that often appear in the mailing list

---Simple Send


This is not a runnable version because you don't need anything but 
REBOL/Core to run it. It has been wrapped in a DO block so it does 
not send errors to the console.

---Quick Send Short Message

 do [
    send [address-:-isp-:-com] "My Message"
 ]
 
---Send Longer Message  

Now a more complex message where there is a body to the message:

 do [
    send [address-:-isp-:-com] {Sample Message
               
    This is the body of the message
    } 
 ]

---Send with One Attachment


Here, so that the sample does not fail, test file(s) are created 
by the code before attempting the send. 

 do [
    test-file: %file-attachment.txt
    write test-file {Just some test data to create a file}
    send/attach [address-:-isp-:-com] {Sample Message
               
    This is the body of the message
    } test-file
 ]
 
---Send with Attachments

And a message with multiple attachments.


Here, so that the sample does not fail, test file(s) are created 
by the code before attempting the send. 

 do [
    files: [%file-attachment.txt %second-attachment.txt]

    foreach file files [write file {Just some test data to create a file}]
    send/attach [address-:-isp-:-com] {Sample Message
               
    This is the body of the message
    } files
 ]
 
---Send to Multiple Addresses


Here, so that the sample does not fail, test file(s) are created 
by the code before attempting the send. 

 do [
    files: [%file-attachment.txt %second-attachment.txt]

    foreach file files [write file {Just some test data to create a file}] 

    send/attach [[address-:-isp-:-com][asecondAddress-:-isp-:-com]] {Sample Message
               
    This is the body of the message
    } files
 ]
 
---Send/only

Same send only just provide the SMTP server with one copy:

Here, so that the sample does not fail, test file(s) are created 
by the code before attempting the send. 

  do [
    files: [%file-attachment.txt %second-attachment.txt]

    foreach file files [write file {Just some test data to create a file}] 

    send/only/attach [[address-:-isp-:-com][asecondAddress-:-isp-:-com]] {Sample 
    Message
               
    This is the body of the message
    } files
 ]
 
---Send With Header


This example uses a Do block to wrap the code. If you execute the 
email should be sent.
But it is unlikely to be delivered.


The addresses for me and you should be changed in your use as well 
as the

* Subject

* Organization

* Content 

 do [
   me: [myaddress-:-isp-:-com]
   you: [youraddress-:-isp-:-com]
   header-object: make system/standard/email [
            From: me
            Reply-To: me
            Subject: "Some Stuff"
            Organization: "Cyberia"
            MIME-Version: 1.0 
            Content-Type: "text/plain"
    ]
 send/header you {Test Message
    This is the message body.
    }                 
    header-object 
 ] 

---Send with CC

This adds a copy value in the header-object

 do [
   me: [myaddress-:-isp-:-com]
   you: [youraddress-:-isp-:-com]
   header-object: make system/standard/email [
            From: me
            Reply-To: me
            Subject: "Some Stuff"
            Organization: "Cyberia"
            MIME-Version: 1.0 
            Content-Type: "text/plain"
        cc: [another-address-:-isp-:-com]
    ]
 send/header you {Test Message
    This is the message body.
    }                 
    header-object 
 ] 


   
---Doctored Code

Again Doc Kimbel's one liner that does not waste a character


 e: field "Email" s: field "Subject" m: area "Body" btn "Send"[send/subject 
 to-email e/text m/text s/text alert "ok"]


===Sharp Styles


I really like the style that Didier has put around his email previewer

 do [
    ss-light: stylize [
        text: text feel none
        vtext: vtext feel none
        col-hdg: text black 255.255.204 bold middle effect []
        col-txt: text edge [size: 1x0 color: gray effect: 'bevel]
        ban: vh3 left to-pair reduce [
            50 logo.gif/size/y] edge [

                color: 0.0.0 size: 0x1] feel none with [color: black]
        lab: label para [origin: 2x3 margin: 0x2]
        labe: lab edge [size: 1x1 color: water effect: 'ibevel]
        inf: info 100 font-color yellow
        bkg: backdrop water - 10.10.10
        txt-big: vtext 300 font-size 18 font-color yellow center
        rti: vtext font-size 14 bold
        txt-ch: rti font-color white 170x22 para [
            origin: 2x3] with [font: make font [
                    color: white] colors: [55.95.155 235.170.55]]
        btnb: btn 70.70.70 font-color white

        men: rti 264 edge [size: 1x1 color: water effect: 'bevel] para [origin: 
        20x2 margin: 1x4]

             with [color: water - 40.40.40 effect: first effects: [

                [draw [pen white fill-pen white polygon 5x2 13x10 5x18]] [draw [pen 
                white fill-pen white polygon 2x5 10x13 18x5]]
             ] feel: none]  ;system/view/vid/vid-feel/hot]

        cbox: box 60x20 edge [size: 1x1 color: water effect: 'bevel] [

            if temp: request-color/color first face/data [face/color: temp change 
            face/data temp show face]
        ] with [append init [color: first data]]
    ]
    stylesheet: ss-heavy: stylize/styles [

        col-hdg: col-hdg effect [gradcol 0x1 200.200.160 155.155.104]

        ban: ban effect [merge gradcol 150.180.200 0.0.0] with [color: none]

        bkg: backdrop effect [gradient 1x1 65.125.175 45.75.115 grid 2000x4 
        1999x4 70.130.190 blur]
        txt-big: vtext 300 font-size 18 font-color yellow center
        rti: vtext font-size 14 bold

        txt-ch: txt-ch effect [gradcol -1x1 105.105.105 151.151.151]
        men: men effect [gradcol -1x0 black water]
    ] ss-light
 ]
    styles stylesheet
    space 4x4 origin 4x4 across
    bkg
    pad 15 ban 235 :title para [origin: 32x0]
    pad -254
    image 30x30 %palms.jpg effect [fit key 255.0.255]
}
code: text: layo: external-view: none
sections: []
layouts: []
space: charset " ^-"
chars: complement charset " ^-^/"

rules: [title some parts]

title: [text-line (title-line: text)]

parts: [
      newline
    | "===" section
    | "---" subsect
    | "!" note
    | example
    | paragraph
]

text-line: [copy text to newline newline]
indented:  [some space thru newline]
paragraph: [copy para some [chars thru newline] (emit txt para)]
note: [copy para some [chars thru newline] (emit-note para)]
example: [
    copy code some [indented | some newline indented]
    (emit-code code)
]

section: [
    text-line (
        append sections text
        append/only layouts layo: copy page-template
        emit h1 text
    ) newline
]
subsect: [text-line (emit h2 text)]
emit: func ['style data] [repend layo [style data]]
emit-code: func [code] [
    remove back tail code
    repend layo ['code 460x-1 trim/auto code 'show-example]
]
emit-note: func [code] [
    remove back tail code
    repend layo ['tnt 460x-1 code]
]

show-example: [

    if external-view [xy: external-view/offset  unview/only external-view]
    xcode: load/all face/text
    if not block? xcode [xcode: reduce [xcode]] ;!!! fix load/all
    if here: select xcode 'layout [xcode: here]
    external-view: view/new/offset layout xcode xy
]

page-template: [
    size 500x480 origin 8x8
    backdrop white - 80

    style code tt snow navy bold as-is para [origin: margin: 12x8]
    style tnt txt maroon bold
]

parse/all detab content rules
show-page: func [i /local blk last-face][
    i: max 1 min length? sections i
    append clear tl/picked pick sections i 
    if blk: pick layouts this-page: i [
        f-box/pane: layout/offset blk 0x0 
        last-face: last f-box/pane/pane    ; bh slider

    f-box/pane/pane/1/size: f-box/pane/size: max 500x480 add 20x20 add 
    last-face/offset last-face/size ; bh slider
    update-slider ; bh slider
        show f-box
    ]

    show tl    ; changed to after slider update ; was not refreshing 
    the index display
]


update-slider: does [
    sld/data: 0
    either object? f-box/pane [
        sld/redrag min 1.0 divide sld/size/2 f-box/pane/size/2
        sld/action: func[face event] compose [

            f-box/pane/offset/2: multiply face/data (subtract 480 f-box/pane/size/2)
            show f-box
        ]
    ][
        sld/redrag 1.0 show sld
        sld/action: none
    ]
    show sld
]

main: layout [
    backtile polished
    across
    vh2 title-line return
    tl: text-list 160x480 bold black white data sections [
        show-page index? find sections value
    ]
    h: at
    f-box: box 500x480

  at h + 500x0 sld: slider 24x480                 ; add brett's slider
    at h + 456x-24
    across space 4
    arrow left  keycode [up left] [show-page this-page - 1]
    arrow right keycode [down right] [show-page this-page + 1]
    pad -150

    txt white italic font-size 16 form system/script/header/date/date
]

show-page 1
xy: main/offset + either system/view/screen-face/size/x > 900 [
    main/size * 1x0 + 8x0][300x300]
view main

ok, so I get list of words .. but can I export (write to file) sources/definitions 
of functions ?  >> source somefunc<< prints it but I would need to 
get a string

I've used ALTER once for user selection in a list, and it was even 
a special case. I think having the ability to just conditionally 
append to a block if the value does not exist is more useful. I.e. 
an ALTER, split in two functions.

Give me a sec, I'll list out the relevant functions...

To know which parameter to pass along you'd need a dialect with a 
list of supported functions in its code.

The R2/Forward functions that are unlikely to be incorporated in 
R2 directly are APPEND, REMOLD and LIST-DIR; the first two because 
they demonstrate the problem with adding too many options to a function, 
and the latter because it isn't good enough yet, even in the R3 version.

One caveat to new options: Once APPLY is backported (planned for 
2.7.8) then new options will need to be added to the end of the options 
list of functions, not in the middle. APPLY is positional when it 
comes to options.

'line-list is only used on "long 'text" face (more than 200 chars 
IIRC). Be carefull with it.


'span was used in View 1.2.1 to set a pixel ratio (zoom) between 
'offset, 'size and correspondng real screen values. I think recent 
beta/alpha does not care of it.

'saved-area is considered if  value is 'true IIRC.


'action is checked by 'feel function, so can be used if 'feel does 
not care of.

'data depends of  'feel too.


'type could be used. Only 'layout or other VID functions use it AFAIK

shadowolf: ok... mine is still a bit backwards. I have a list object 
which contains all list functions and the raw layout for the list. 
when I want to use the list, I create a box in a layout and assign 
it to the pane of that box, voila. :-) the list adapts to the size 
of the box, so I think live resizing would work though columnsizes 
are still fixed

Anyone know what happened to all the registry functions in View 1.3?


   create-reg      native!   Creates a registry key and returns TRUE 
   on success...

   delete-reg      native!   Deletes a registry key. Returns TRUE if 
   deleted. (...

   exists-reg?     native!   Returns TRUE if registry key exists. (HKCU 
   is defa...

   get-reg         native!   Returns value of a registry key, else NONE. 
   (HKCU ...

   list-reg        native!   Returns a block of sub-keys for a registry 
   key. (H...

   set-reg         native!   Sets registry key value. Returns value 
   on success,...
   unset-reg-funcs function! []

I hope they aren't gone for good!

http://www.compkarori.com/vanilla/display/list+examples


Here is documented the face, count and index variables.  There are 
similar functions throughout VID.

such thing should be done via accessor functions - set-face, get-face

 - i think Carl changed philosophie here. The old vid is good for 
 simple forms. Why use an accessor when you simply can inline the 
 data into the layout? But it works not so well when you want to change 
 displayed data. Text-list for example where not even prepared to 
 have data updated. thats where accessors come in. instead of re-layout 
 reuse the old faces and change their values.

shell-list allows functions to be placed in the map dialect block, 
which is kind of like your /explicit refinement above. The automatic 
iterates are found in the default-iterates block.

Sorry, Robert. There is something I want to announce. :-)


http://hmkdesign.dk/list-test.png<--- a picture of the list view 
I'm building.


Currently about half done and quite usable at this time: It's resizable. 
Values are stored as blocks of blocks. All columns can be sorted. 
Input columns can be filtered so you can show only some columns. 
Columns can be freely reordered (but not in the GUI yet). One arbitrary 
column can be resized.

It has the normal range of series manipulation functions available 
in REBOL. There is also possibility for inline editing, by doubleclicking 
a line. Changed values are automatically stored in the list. All 
such operations are "bundled" in the list view VID code and you only 
need to provide whatever functions needed to store the list data 
in an external place. If a text entry is too wide, it'll be neatly 
cut with ellipsis (...).

Filtering function, to filter input by rows. Also has a scroll-to-selected-line 
function.

It's about as fast as the current LIST in VID, since it really is 
LIST with just a whole bunch of extra functions to make general list 
views easy. There are functions possible for clicking and double 
clicking and functions for retrieving rows and columns.


Current limitations: No mouse over indication (can't make it fast 
enough). Only one resizable column. No keyboard navigation. No horizontal 
scrolling. No scroll-wheel support. It doesn't integrate 100% with 
VID yet. I'm using some of my own widgets and bitmap graphics from 
a pretty big GUI library. Stripe look, font and coloring is locked. 
No standard settings yet for the list view.

All code is about 250 lines.


Planning: Reordering columns via drag'n'drop. Column resizing, if 
I can figure it out. Format the font object conditionally from list 
input (make this line bold if the age column is > 45 years, etc.). 
Grid drawing. Images in list rows. And if I can get around to it: 
Single cell in-line editing ala spreadsheets. :-)

sorry for the wait... Version 0.0.8 uploaded

Changes:

      New: Functions to select next, previous, next page, previous page, 
      first and last. Uses FOLLOW.

      New: FOLLOW. Automatically follows the selected entry so it's always 
      in view. Requires FOLLOW? set to TRUE

      New: SCROLL-HERE. Scrolls automatically to the selected entry.
      Fix: Filter result was lost after resize.
      Fix: Sorting was lost after resize.
      Fix: Sorting indication is now persistent after resize.
      Fix: Dual state sorting was accidentally broken.
      New: Initial sorting can now be set before first view
      New: Right-click on header unsorts the list

Demo can be found at http://hmkdesign.dk/rebol/list-view3.r

uploaded 0.0.11

Changes:

      New: Header can now be defined from the words in OUT-COLS or IN-COLS

      New: No longer need to manually create the subface for the list
      Fix: DATA was not properly initialized

      Fix: List was updated twice during all manipulation functions added 
      in 0.0.10

      New: Added /no-show refinement to FLT-LIST to speed up certain updates 
      that require setting the selected row before showing

version 0.0.14 uploaded

Changes:
      Fix: Documentation updates
      Fix: Multiple lists accidentally shared the LIST-SIZE value
      New: Custom layout block can now have multiple rows
        at the cost of horizontal resizability
      New: Now using ROW-FACE to store the custom layout block
      New: If HDR-COLS is set to a single word in a block,
        it will take the width of the list view.
      Fix: Code size optimization of navigation functions

      Info: The version between 0.0.12 and 0.0.14 is mysteriously missing... 
      :-)


The demo has been changed a bit to test custom layouts and multiple 
lists.

http://www.hmkdesign.dk/rebol/list-view.r
http://www.hmkdesign.dk/rebol/list-view.html

LIST-VIEW version 0.0.16 uploaded.

Changes:

      Fix: LAST-CNT crashed on empty SORT-INDEX after filtering

      New: FILL flag to set whether or not to paint all rows in the list 
      view

      New: COLORS/4 contains the color of the background behind the rows.

      New: When resizing OUT-COLS in runtime, WIDTHS is reset to default 
      values

      Fix: Columns can now be appended or removed to OUT-COLS in runtime
      Fix: Changed behaviour so that DATA is always treated as
        a block of blocks if manipulated by LIST-VIEW itself.

        Only external input of a single block value can change this.
      Fix: INSERT-ROW-HERE, REMOVE-ROW-HERE, CHANGE-ROW-HERE
        failed on empty DATA
      New: Stricter typechecks on manipulation functions
      Fix: Values are now copied into DATA
      Fix: Sorting did not work, when using only one DATA column

      New: Allows using keyed blocks as input for manipulating functions.

      Fix: Header size now calculated with OUT-COLS also, which removes 
      a crash
      New: Created a test suite in file list-demo.r
      New: Moved demo code out of this file

    Main file is available at:
    http://www.hmkdesign.dk/rebol/list-view/list-view.r
    Demo and testcases available at:
    http://www.hmkdesign.dk/rebol/list-view/list-demo.r
    Docs are available in makedoc2 format at:
    http://www.hmkdesign.dk/rebol/list-view/list-view.txtand
    http://www.hmkdesign.dk/rebol/list-view/list-view.html

LIST-VIEW 0.0.17 uploaded.

Changes:

      Fix: FILTER was broken. Seems to be a bug in clearing bitsets.

      New: EDT-FLD-ACT and EDT-LST-ACT to let you perform functions when 
      tabbing out of an inline editing field

      Fix: Column selecting marked columns beyond the end of DATA.

      Fix: Fractional widths are now properly resized, when resizing the 
      list

      New: Inline Editing! Can be activated with the EDITABLE? flag (default 
      on)

James, it is quite difficult to make an iterated list of AREAs using 
LIST, retaining all the correct behaviour as expected for an AREA. 
I remember trying pretty mightily to achieve this, but, in the end, 
I have no example to show. If you were going to try, you would program 
the pane function directly yourself, rather than letting LIST use 
its default pane functions.

So I recommend the approach, as Graham above, of generating real 
faces (at least for the visible part of your list).

To track it down, I patched all functions (and relevant, nested helper 
functions) involved in Sunanda's example code: VIEW REQUEST-LIST 
INFORM SHOW-POPUP HIDE-POPUP and finally WAKE-EVENT. I added 30 print 
statements to all those function bodies (making sure to bind them 
correctly etc), tracking the control flow, then compared the output 
before and after escape was pressed. Eventually I found the difference 
in control flow in wake-event (EITHER POP-FACE ...).

Multiple refinement functions :  I need to formulate a function with 
more than one refinement.  I know in Rebol we usually use the word 
'either to formulate them, but with more than 3 refinements (and 
its following default case) it becomes tedious.   Structures like 
'record-operations: func [/delit /addit /modit] [ either  delit [print 
"delete"] [either addit [print "add"] [either modit [print "modify"][print 
"no refinement"]]]]'  are overly complicated.  I would like a more 
flat structure, to be able to distinguish the conditions which are 
independants from the ones mutually dependants, albeit mutually exclusive. 
 I tried multiple if's but that does not seem to work.  What are 
the good options to code multiple refinements functions.  The mail 
list does not seem to have an example discussing just that.  And 
in the source, most functions with multiple refinements are native.

; I did a dif between the functions in VIEW and those in CORE for 
a default install.  What I get is this ( I hope it is useful to have 
al 106  in one place )

 alert  brightness?  caret-to-offset  center-face  choose  clear-face 
  clear-fields  confine  crypt-strength?

 dbug  deflag-face  desktop  dh-compute-key  dh-generate-key  dh-make-key 
  do-events  do-face  do-face-alt  do-thru  

 draw  dsa-generate-key  dsa-make-key  dsa-make-signature  dsa-verify-signature 
  dump-face  dump-pane  edge-size?  

 editor  emailer  exists-thru?  find-key-face  find-window  flag-face 
  flag-face?  flash  focus  get-face  

 get-net-info  get-style  hide  hide-popup  hilight-all  hilight-text 
  hsv-to-rgb  in-window?  inform  

 insert-event-func  inside?  install  launch-thru  layout  link-relative-path 
  load-image  load-stock  

 load-stock-block  load-thru  local-request-file  make-face  notify 
  offset-to-caret  open-events  outside?  

 overlap?  path-thru  read-net  read-thru  remove-event-func  request 
  request-color  request-date  request-dir  

 request-download  request-file  request-list  request-pass  request-text 
  reset-face  resize-face  rgb-to-hsv  

 rsa-encrypt  rsa-generate-key  rsa-make-key  screen-offset?  scroll-drag 
  scroll-face  scroll-para  set-face  

 set-font  set-para  set-style  set-user  show  show-popup  size-text 
  span?  stylize  textinfo  unfocus  

 uninstall  unlight-text  unview  vbug  view  viewed?  win-offset? 
  within?

REBOL []

do %include.r
include %file-list.r


flash-wnd: flash "Finding test files..."

if file: request-file/only [
    files: read first split-path file
]
if none? file [halt]

items: collect/only item [
    foreach file files [item: reduce [file none]]
]

unview/only flash-wnd



;-------------------------------------------------------------------------------
;-- Generic functions

call*: func [cmd] [
    either find first :call /show [call/show cmd] [call cmd]
]

change-each: func [
    [throw]

    "Change each value in the series by applying a function to it"

    'word   [word!] "Word or block of words to set each time (will be 
    local)"
    series  [series!] "The series to traverse"

    body    [block!] "Block to evaluate. Return value to change current 
    item to."
    /local do-body
][
    do-body: func reduce [[throw] word] body
    forall series [change/only series do-body series/1]

    ; The newer FORALL doesn't return the series at the tail like the 
    old one

    ; did, but it will return the result of the block, which is CHANGE's 
    result,
    ; so we need to explicitly return the series here.
    series
]

collect: func [
    "Collects block evaluations." [throw]
    'word
    block [block!] "Block to evaluate."
    /into dest [block!] "Where to append results"
    /only "Insert series results as series"

    /local fn code marker at-marker? marker* mark replace-marker rules
][
    block: copy/deep block
    dest: any [dest make block! []]

    fn: func [val] compose [(pick [insert insert/only] not only) tail 
    dest get/any 'val

        get/any 'val
    ]
    code: 'fn
    marker: to set-word! word
    at-marker?: does [mark/1 = marker]
    replace-marker: does [change/part mark code 1]
    marker*: [mark: set-word! (if at-marker? [replace-marker])]
    parse block rules: [any [marker* | into rules | skip]]
    do block
    head :dest
]

edit-file: func [file] [
    ;print mold file

    call* join "notepad.exe " to-local-file file ;join test-file-dir 
    file
]

flatten: func [block [any-block!]][
    parse block [

        any [block: any-block! (change/part block first block 1) :block | 
        skip]
    ]
    head block
]

logic-to-words: func [block] [

    change-each val block [either logic? val [to word! form val] [:val]]
]

standardize: func [

    "Make sure a block contains standard key-value pairs, using a template 
    block"
    block    [block!] "Block to standardize"
    template [block!] "Key value template pairs"
][
    foreach [key val] template [
        if not found? find/skip block key 2 [
            repend block [key val]
        ]
    ]
]

tally: func [

    "Counts values in the series; returns a block of [value count] sub-blocks."
    series [series!]
    /local result blk
][
    result: make block! length? unique series

    foreach value unique series [repend result [value reduce [value 0]]]
    foreach value series [
        blk: first next find/skip result value 2
        blk/2: blk/2 + 1
    ]
    extract next result 2
]


;-------------------------------------------------------------------------------

counts: none

refresh: has [i] [
    reset-counts
    i: 0
    foreach item items [
        i: i + 1
        set-status reform ["Testing" mold item/1]
        item/2: random/only reduce [true false]
        show main-lst
        set-face f-prog i / length? items
        wait .25
    ]
    update-counts
    set-status mold counts
]

reset-counts: does [counts: copy [total 0 passed 0 failed 0]]

set-status: func [value] [set-face status form value]

update-counts: has [pass-fail] [
    counts/total: length? items

    pass-fail: logic-to-words flatten tally collect res [foreach item 
    items [res: item/2]]
    ;result (e.g.): [true 2012 false 232]
    standardize pass-fail [true 0 false 0]
    counts/passed: pass-fail/true
    counts/failed: pass-fail/false
]

;---------------------------------------------------------------


main-lst: sld: ; The list and slider faces
c-1:           ; A face we use for some sizing calculations
    none
ml-cnt:        ; Used to track the result list slider value.
visible-rows:  ; How many result items are visible at one time.
    0

lay: layout [
    origin 5x5
    space 1x0
    across

    style col-hdr text 100 center black mint - 20

    text 600 navy bold {

        This is a sample using file-list and updating progress as files are
        processed. 
    }
    return
    pad 0x10

    col-hdr "Result"  col-hdr 400 "File" col-hdr 100
    return
    pad -2x0

    ; The first block for a LIST specifies the sub-layout of a "row",

    ; which can be any valid layout, not just a simple "line" of data.

    ; The SUPPLY block for a list is the code that gets called to display

    ; data, in this case as the list is scrolled. Here COUNT tells us

    ; which ~visible~ row data is being requested for. We add that to 
    the

    ; offset (ML-CNT) set as the slider is moved. INDEX tells us which
    ; ~face~ in the sub-layout the data is going to.

    ; COUNT is defined in the list style itself, as a local variable 
    in
    ; the 'pane function.
    main-lst: list 607x300 [
        across space 1x0 origin 0x0
        style cell text 100x20 black mint + 25 center middle
        c-1: cell  cell 400 left   cell [edit-file item/1]
    ] supply [
        count: count + ml-cnt
        item: pick items count
        face/text: either item [
            switch index [
                1 [

                    face/color: switch item/2 reduce [none [gray] false [red] true [green]]
                    item/2
                ]
                2 [mold item/1]
                3 ["Edit"]
            ]
        ] [none]
    ]

    sld: scroller 16x298 [ ; use SLIDER for older versions of View

        if ml-cnt <> (val: to-integer value * subtract length? items visible-rows) 
        [
            ml-cnt: val
            show main-lst
        ]
    ]
    return
    pad 0x20
    f-prog: progress 600x16
    return
    status: text 500 return
    button 200 "Run" [refresh  show lay]
    pad 200
    button "Quit" #"^q" [quit]
]

visible-rows: to integer! (main-lst/size/y / c-1/size/y)

either visible-rows >= length? items [
    sld/step: 0
    sld/redrag 1
][
    sld/step: 1 / ((length? items) - visible-rows)
    sld/redrag (max 1 visible-rows) / length? items
]

view lay

Refinements are options, sometimes used in twos or threes, and the 
disadvantage here is that the argument list then can become hard 
to read. It's a good skill to create functions without too many refinements. 
I personally consider refinements to be one of the less stellar parts 
of REBOL.

A few of my personal favorite features though are type-ahead-find 
and "find all in one file", "search across files". I guess it wouldn't 
be hard to parse the file to list all functions, would it? Oh, and 
a line numbering thingy too :-) I don't think that would slow it 
down too much.

Gregg wrote (in group Rebol vs Scheme):

I would *love* to see mini-primers on language design for Lisp, Forth, 
Logo, etc. in REBOL.

I've taken the first step for a BASIC dialect:

do http://www.fys.ku.dk/~niclasen/rebol/basic.r

It only knows a few commands so far: auto list new old
And these statements: end goto print rem run
And these functions: cos sin

So far this is implemented:

Keywords: AUTO, DELETE, LIST, NEW, OLD, GOTO, RUN, END, IF, INPUT, 
LET, PRINT, REM, STOP
Functions: COS, SIN
Expressions can beside unary +, - use: +, -, *, /, ^, (, )
Conditions can use: or, eor, and, =, <>, <=, >=, <, >

New version 0.1.1 of BBC BASIC. Added many keywords, mostly functions. 
To run:
>> do http://www.fys.ku.dk/~niclasen/rebol/bbcbasic.r

List of keywords: http://www.fys.ku.dk/~niclasen/rebol/bbcbasic.html

R2-Forward has been released! Now you don't necessarily have to wait 
for R3 to get finished - use the new functions in R2 now :)

Released to DevBase (aka R3 chat) in Community/Libraries/R2-Forward 
(837). Tested in 2.6.2, 2.7.5 and 2.7.6. Take a look!

Stats: 72 words exported, 49999 chars, 41522 LM, 29730 LMF, 8379 
LMFC.


Obviously, there are whole categories of stuff that won't be backported; 
the notes say what is supported. You'd be surprised what I *have* 
managed to backport though - even some datatypes are spoofed :)


Discussions in R3 chat #837, or the Core group here. More testing 
is welcome - I'd like to push my tested platforms back as far as 
2.5.0 if I can. My todo list for R2-Forward is pretty extensive...

So how to best handle data now? For example I want to handle a todo 
list, where I need to change position of the todos in the list. Does 
the widget works with copy of the data best, or can I link it directly 
with the data block that the other functions work with too?

line-list is the culprit. Replace the 'show-text and 'clear-text 
functions in %rebgui.r with the following:

show-text: make function! [
	"Sets a widget's text attribute."
	face [object!] "Widget"
	text [any-type!] "Text"
	/focus
][
	face/line-list: none
	insert clear face/text form text

 all [face/type = 'area face/para face/para/scroll: 0x0 face/pane/data: 
 0]
	either focus [ctx-rebgui/edit/focus face] [show face]
]

clear-text: make function! [
	"Clears a widget's text attribute."
	face [object!]
	/no-show "Don't show"
	/focus
][
	face/line-list: none
	clear face/text

 all [face/type = 'area face/para face/para/scroll: 0x0 face/pane/data: 
 0]
	unless no-show [
		either focus [ctx-rebgui/edit/focus face] [show face]
	]
]

Had a look at porting Henrik's list-view over to RebGUI. Main challenge 
would be to convert / merge 4 styles (list-icon, list-field, list-text 
and list-view) into a single rebface. This would require quite a 
bit of code restructing. The actual internals don't need too much 
work (functions and feel code are pretty VID/RebGUI neutral), but 
a lot of references to RebGUI 'standards' need to be added; such 
as:

	default-* objects instead of system objects
	ctx-rebgui/sizes
	ctx-rebgui/colors


And the span facet needs to be added (and support logic added) to 
enable dynamic resize / rescale. Given the amount of code that needs 
to be changed, I don't believe a VID and RebGUI version can be [easily] 
built from the same code-base (i.e. the port will in effect create 
a fork).


Also, from a code complexity POV, the list-view widget is almost 
as large as *all other widgets combined* ... and it includes functionality 
that could probably otherwise go into a grid / spreadsheet type widget 
(list-view is almost a GUI framework in its own right now! ;)). If 
anyone's in doubt, I think Henrik's work rocks and fills a much needed 
gap in VID functionality. ;)

Robert

 Docs: the 'Widgets' section of the 'RebGUI Display User's Guide' 
 is already in the Repository (the WidgetList Wiki entry) ... I'll 
 be removing that section from the guide once all the widget details 
 have been copied across. Feel free to update the Wiki with any widget 
 specific usage notes / instructions. Forward any other doc changes 
 to me and I'll put them in. I plan to eventually move all the docs 
 across to the Wiki, just haven't got around to doing it yet.

 "do you first want to take a look at the changes or should I just 
 check them in?" ... Just check them in thanks.
	screenshots: added to the ToDo list

 widget placement: I'm coming around to the idea that BELOW may be 
 unavoidable, even if undesirable from a design / complexity POV
	tabbing: Anton about summed it up

Volker
	Type: also used by accessor functions

First cut attempt at set- functions to replace various show- functions:

set-attribute: make function! [
	face [object!] "Window dialog face"
	attribute [word!] "Attribute to set"
	value [any-type!]
	/no-show "Don't show"
	/focus
] [
	face/:attribute: case [
		string? value		[
			face/line-list: none

   all [face/type = 'area face/para face/para/scroll: 0x0 face/pane/data: 
   0]
			form value
		]
		series? value		[copy value]
		attribute = 'color	[either word? value [get value] [value]]
		true				[value]
	]
	unless no-show [
		either focus [ctx-rebgui/edit/focus face] [show face]
	]
]

set-attributes: make function! [
	face [object!] "Window dialog face"
	attributes [block!] "Block of attribute/value pairs to set"
	/no-show "Don't show"
] [
	foreach [attribute value] attributes [
		set-attribute/no-show face attribute value
	]
	any [no-show show face]
]

Used like this:

	display "" [
		b: box
		button "A" [set-attribute b 'color red]
		button "B" [set-attributes b [color blue effect arrow]]
		button "Clear" [set-attributes b [color none effect none]]
	]

- display now returns face

 - clear-widget uses radio-group/select-item and table/text-list select-row
 - table/rows attribute added to complement table/cols
 - text-list/rows attribute added
 - get-input and set-input funcs added


These later functions allow you to easily get and put values into 
a display or tab-panel, even one containing nested grouping widgets 
such as 'group-box or 'tab-panel. Handles the following input widgets: 
area check check-group drop-list edit-list field group-box password 
radio-group slider tab-panel table text-list.


The /type refinement of get-input is usefull in design/debug mode 
to get a formatted list of widget type/value pairs.

Example code to demonstrate the use of these two functions.

d: display "Test" [
	after 3
	area "area"
	check true
	check-group data ["check" true]
	drop-list data ["drop-list"]
	edit-list data ["edit-list"]
	field "field"
	group-box "group-box" data [
		field "field"
	]
	password "password"
	radio-group data [1 "radio-group"]
	slider data .5
	tab-panel data ["A" [field "Tab-panel"] "B" []]
	table options ["col" left 1.0] data ["row1" "row2"]
	text-list data ["line1" "line2"]
	button [a: get-input d b: get-input/type d halt]
	button [

  put-input d ["Text" true [false] "A" "B" "text" ["xx"] "" 1 1 ["Bob"] 
  [1] [2]]
		show d
	]
]

Uploaded build#81 to SVN. Includes the following changes:

	Fixed label & text auto-sizing (now defaults to -1x-1)
	Spinner now accepts an empty starting value
	hilight-on-focus now works again

 [edit-list field password spinner] are now hilight-on-focus (area 
 remains caret-on-focus)
	edit-list fix

Also updated:
	http://www.dobeash.com/RebGUI/widgets.html
	http://www.dobeash.com/RebGUI/functions.html

Robert, yes. Your tree-view widget is a superset of what I need / 
want (and is 21Kb vs my 3Kb).


Ideally, I'd like every widget to be 5kb or under, with 10kb a max. 
After developing and merging over 40 widgets I've come to the following 
conclusions:

1) 90% of the basic usage cases can be coded in under 5kb
2) Double the code size to increase this to 95%
3) Quadruple this size to get it to 99%

4) Time required to maintain / fix and document a widget increases 
exponentially as code size increases

5) A widget that tries to do many things is no longer a widget ... 
it is an app (list-view and grid fall into this category)

6) While developing the sheet and tree widgets I came to the realization 
that the scroller logic could be externalized in another widget (scroll-panel) 
thus removing much of the duplicated scroller handing code found 
in a number of widgets


Where does this leave grid? Near as I can figure it's a combination 
of table and sheet, but supporting cell types other than plain old 
field. I can see how folks want to pull data from a DB and put it 
into a grid, so does that mean we have 'typed' columns or can every 
cell be different. If the later, then aren't we just talking about 
a sheet with support for more datatypes?


And now for the accessors. We obviously want functions to load and 
save data, put and get cells, and add / delete rows; but do we really 
need functions to move columns around? Or hide and reveal columns? 
It's very easy (and tempting) to over-engineer ... but keeping things 
as simple as possible (but no simpler) makes for a stable system 
that is easily fixed, extended, maintained and documented.

Yes, text focus is implemented via View's caret handling functions 
which enable portions of text to be highlighted ... contrasted with 
list widgets which either highlight the entire row (or not).

Build 211
- Moved base objects from ctx-rebgui to system/view
- Removed all dependencies on View/VID mezz code
- Rewrote and added show-popup & hide-popup functions
- Removed style widget
- Inlined popup logic
- Converted internal images from base 16 to base 64
- Cursor keys now work in choose (drop-list, edit-list & menu)
- pad option in layout enhanced to accept pair! (pixels)
- Added tooltips to tool-bar
- Added request-edit
- Improved resize logic
- Fixed request-dir (resize bug)
- Fixed slider (resize bugs)

If this list doesn't fulfill all your needs, here's the additionnal 
features planned for the 1.0 release :

    * RSP: REBOL Server Pages support.
    * General CGI support (run any CGI script).

    * Chunk-encoding transferts support (streamed data transferts).
    * Standard compression methods support: gzip, deflate, bzip2.

    * Byte-ranges request support (ability to request files in parts 
    and resume broken downloads).

    * mod-rewrite module for powerful request URL transformations (without 
    the regexp complexity!).

    * mod-map-url module for direct URL to REBOL functions or objects 
    mapping.
    * SSL support.
    * Advanced GUI client for local and remote administration.

Anyway, I hope the above list can help to get a rough idea of which 
functions should be studied first.

I think just the list of natives would be a good start then use the 
source for the mezzanine functions as excersize of what can be done.

Example problems I would give my students to solve would look like 
(to be adjusted according to the native word set retained):


Using iteration, draw a 19 line isoceles triangle (concepts of looping 
not obvious for beginners, but essential to grasp early)


Find all prime numbers lower than a given one, using previously found 
primes in the process to speed up the search.


Given a list of adresses, get the files and identify which ones have 
a given information on them (elementary parsing)


... Things like that. Diversified enough to give a good feel of what 
programming can solve while gaining basic skills (data stores, interation, 
maybe recursivity, various control structures - not necessarily all 
of them, operators, native functions and user defined functions, 
input and output, ...)

Each of those functions I am referring to has their own parameter 
list.

today I discovered maybe fairly obvious thing about rebol, that was 
bugging me for long time and I thought there is no solution:
compose [ ([]) ] == []
compose [ ([ 1 2 3 ]) ] == [ 1 2 3 ] 


I just assumed taht compose functions the same way as reduce and 
never looked in details. And there were many instances where I would 
need such behaviour and I had to invent worse solutions because I 
didn't think it was possible with rebol.


I had it as one sign that rebol is not as mature as lisps because 
there you have @to deconstruct list in such a manner. But now I see 
we have even cleaner solution also.

In C1 and C2 you are creating new functions and assigning them to 
their 'b fields. In C3 you are just making a rebound copy of the 
function created in C1, which still has an [a] argument block. Changing 
the value of the object field a doesn't change the argument list 
of the function assigned to the object field b after that function 
has been created.

Q: What does the world on Nov-15-2005 look like?


A: Our main goal is to get REBOL into the hands of more users, not 
just programmers and techies.... by the millions over time.  By doing 
that, we create a market for not only handy free REBOL apps, but 
also for commercial apps and entire businesses that are related to 
REBOL.



Q: Given that  window transparency is OS specific, will there be 
a dialect that covers both Windows, Linux and 40+ other OS?  In other 
words, does RT plan on continued support of so many languages, or 
are we entering a new era of specific OS support?


A: Our plan is to make that a window option that is part of the face/options 
for a window.  If an OS does not support this mode, then the option 
will be ignored, but the application will still be fully functional.



Q: I hope it is still valid that cooperation with RT is possible. 
I mean - last few weeks I play with some Win32 functions (thanks 
to Gregg) and I would like we would have proper app behavior in multi-monitor/multi-desktop 
environments .... so I wonder if any SIGs will be created, some ppl 
will be invited to participate, comment etc., or if RT is gonna cook 
it all themselves?


A: Yes, there are many such special interest projects currently going 
on. (Most of them are occurring via private projects in AltME and 
IOS.)  These days 90% of REBOL changes are done in cooperation with 
the REBOL community.



Q: Hi .... with recent Rebcode releases, we can see that internally 
new Core is marked as 2.7 and View is marked as 1.4 Is it just working 
"title" or will those products be marked as that? And if so, can 
we know, what other changes will go for 1.4 View release target? 
Will there be any AGG fixes/additions (to support SVG RebGUI progress), 
or even VID changes? I still think, that VID is missing few fine 
styles as tab, group-box, better list as was introduced on IOS Developer's 
server, (eventually tree, menu), to allow novices to start using 
VID/View more productively. Any chance RT can tell us, what is the 
plan for 1.4 release?


A: Regarding 2.7 and 1.4 question: we change the revision numbers 
(the second number) whenever there is a major change in REBOL that 
may be unstable.  The /core 2.7 kernel (that is in /view 1.4 as well) 
adds new datatypes to REBOL, and they are the first datatypes added 
in several years, so we consider this to be a major change, and marked 
it that way.
Yes, we do plan to be making a few AGG fixes very soon.

Oh, and regarding VID: we plan to be making very big changes there. 
More to come soon.


Q: Could you add struct! support to /Core?

I keep on having situations that would be made much easier by struct! 
when I don't need libraries. For instance, conversions from external 
binary data encodings to internal REBOL values, say for file formats, 
network protocols and so on. Now rebcode has added other forms of 
strong typing like the type-specific opcodes and the vectors. Having 
structs with their constrained field types, their specific data layouts, 
would be a perfect match for the low level operations of rebcode. 
They would be helpful later when implementing your own data types 
as well.


A: On structs: yes, we will enable this feature on core, but it should 
only be used for lower level code.  Objects are more powerful.


Q: Could you add an APPLY opcode to rebcode?

    apply: ["Apply function or path to arguments, save result" word! 
    word! | path! block!]

In rebcode:
    apply x f [arg1 arg2 ...]
Is equivalent to this in REBOL:
    x: do f arg1 arg2 ...


The advantage to doing function calls this way is that the arity 
of the opcode is fixed, even if the arity of the function called 
can't be known ahead of time. The value assigned to the function 
word could be either a function or a path, or for efficiency you 
could have a seperate opcode APPLYP for path values (I'd prefer just 
one opcode for generality but it's your call).


A: I'm not sure what is meant by the path for it. You mean for refinements?
That may actually slow down the apply interface.

Q: (note - my view may be influenced by insufficient knowledge in 
the area given) - last weeks I played with wrapping some Win32 functions. 
I started discussion on dll.so channel, to ask developers, if they 
would enhance interfacing to C libraries in some way, and there was 
few ideas appearing. We currently have also rather strange callbacks 
support (limited to 16) and I would like to ask, taking into account 
that DLL interface in Rebol was not changed/enhanced since it appeared 
long time ago, if RT sees any area in which it could be made more 
robust, developers friendly etc.?


A: We are planning to do a lot more on DLLs. In fact, future versions 
of REBOL will expand on the way DLLs are used in REBOL.   For example, 
I would like to see DLL support for media loaders and savers, so 
if we do not directly support a specific type of media file (say, 
TIFF) then an external DLL can be provided to load it.  There are 
a few other DLL related features down the road, but it is still a 
bit early to talk about them.



Q: I realize that the open sourcing of the viewtop wasn't that successful, 
but do you still intend to keep releasing newer versions of it? AFAIK 
the current release is over a year old. I've experienced a lot of 
obvious bugs in the viewtop editor, which I think can easily be solved 
by people outside RT.


A: yes we will continue to release newer versions.  View 1.3.2 fixed 
a number of bugs in the Viewtop editor that were listed in on RAMBO. 
Any fixes and enhancements from the community are greatly appreciated 
(by everyone, not only RT!)  You can post them to RAMBO, and we will 
review and include them (if they look good).



Q: While reviewing the action! functions, I noticed the path action. 
The doc comment says "Path selection.". The parameters aren't typed. 
Does anyone know what this action does, and how to use it? Or whether 
it can be or should be called directly at all?


A: the PATH action is what the interpreter uses to evaluate VALUE/selector 
expressions for each datatype. It is an internal action and has no 
external purpose in programs. These kinds of words often appear as 
a sort of "side-effect" from how REBOL is structured.  Datatypes 
are implemented as a sort of object class, where the interpreter 
"sends messages" to the class to evaluate expressions. The PATH action 
is a message that tells the datatype to perform a pick-like or poke-like 
internal function.


Q: Is rebcode going to support paths and/or some kind of binding?


A: Certain rebcode can support anything we feel is important to put 
into it, but note: many things we add could slow it down, by a lot. 
 For example, if we were to allow paths as variables, I estimate 
that rebcode would be about two times slower than it is now.  Perhaps 
one way to solve this issue is for you to use COMPOSE prior to specifying 
your rebcode body.  Within the compose, you can use IN object 'word 
to "pre-compute" the context references for words. For example:

    add.i (in object 'num) 10


Your question about binding is not clear to me. Rebcode already supports 
binding. Your rebcode can be part of an object context, and rebcode 
function words are bound to the code context.  (Perhaps you are referring 
to an older bug that has since been fixed?)



Q: What do you think about  http://mail.rebol.net/maillist/msgs/39493.html
? Why not say a word in your blog, if you think that it's interessant 
for rebol developpment, and if you want to contact them ?


A: Recently, I had the chance to sit down and talk with one of the 
main people from the One Laptop Per Child project (he is a friend 
of mine from Apple Computer days).  The project has an interesting 
goal, but there are also many difficult issues around it (not just 
in the technical side, but also on the social and cultural sides). 
My current understanding is that the target software is Smalltalk 
based. Yes, it would be very interesting to allow REBOL on that system, 
but if you look at the list of principals for the project, you will 
see that such a revolution is unlikely.  Is it possible that perhaps 
REBOL could provide some additional capability in the future? I think 
so. We have some special plans that I think will bring REBOL to platforms 
like that in the future. But, this is too early to say more.



Q: 1. What is fixed/added in 2.6.2/1.3.2 (change-log, please) ? 2. 
What is planned for 1.4.0 (rebcode, rebservices, rich-text, RIF, 
and last but not least, fixed sound ...) ? 3. When can we expect 
1.4.0 ? Thanks.


A: 1. Gregg is preparing a summary. The document should be available 
this week. 2. We are evaluating a large variety of changes in REBOL, 
more than even the 1.4 release that we've talked about.  I hope to 
be able to say more about these plans soon.

Marketing Ideas to lawyers
AN ARTICLE FROM SUNDAY'S NEW YORK TIMES WE SHOULD READ CAREFULLY.


Awaiting the Day When Everyone Writes Software

By JASON PONTIN
Published: January 28, 2007

BJARNE STROUSTRUP, the designer of C++, the most influential programming 
language of the last 25 years, has said that “our technological civilization 
depends on software.” True, but most software isn’t much good. Too 
many programs are ugly: inelegant, unreliable and not very useful. 
Software that satisfies and delights is as rare as a phoenix.

Skip to next paragraph

Sergei Remezov/Reuters

Charles Simonyi, chief executive of Intentional Software, in training 
for his trip to the International Space Station, scheduled for April.

Multimedia
Podcast: Weekend Business

Reporters and editors from The Times's Sunday Business section offer 
perspective on the week in business and beyond.

How to Subscribe

All this does more than frustrate computer users. Bad software is 
terrible for business and the economy. Software failures cost $59.5 
billion a year, the National Institute of Standards and Technology 
concluded in a 2002 study, and fully 25 percent of commercial software 
projects are abandoned before completion. Of projects that are finished, 
75 percent ship late or over budget.


The reasons aren’t hard to divine. Programmers don’t know what a 
computer user wants because they spend their days interacting with 
machines. They hunch over keyboards, pecking out individual lines 
of code in esoteric programming languages, like medieval monks laboring 
over illustrated manuscripts.


Worse, programs today contain millions of lines of code, and programmers 
are fallible like all other humans: there are, on average, 100 to 
150 bugs per 1,000 lines of code, according to a 1994 study by the 
Software Engineering Institute at Carnegie Mellon University. No 
wonder so much software is so bad: programmers are drowning in ignorance, 
complexity and error.


Charles Simonyi, the chief executive of Intentional Software, a start-up 
in Bellevue, Wash., believes that there is another way. He wants 
to overthrow conventional coding for something he calls “intentional 
programming,” in which programmers would talk to machines as little 
as possible. Instead, they would concentrate on capturing the intentions 
of computer users.


Mr. Simonyi, the former chief architect of Microsoft, is arguably 
the most successful pure programmer in the world, with a personal 
fortune that Forbes magazine estimates at $1 billion. There may be 
richer programmer-billionaires — Bill Gates of Microsoft and Larry 
Page of Google come to mind — but they became rich by founding and 
managing technology ventures; Mr. Simonyi rose mainly by writing 
code.


He designed Microsoft’s most successful applications, Word and Excel, 
and he devised the programming method that the company’s software 
developers have used for the last quarter-century. Mr. Simonyi, 58, 
was important before he joined Microsoft in 1981, too. He belongs 
to the fabled generation of supergeeks who invented personal computing 
at Xerox PARC in the 1970s: there, he wrote the first modern application, 
a word processor called Bravo that displayed text on a computer screen 
as it would appear when printed on page.


Even at leisure, Mr. Simonyi, who was born in Hungary and taught 
himself programming by punching machine code on Russian mainframes, 
is a restless, expansive personality. In April, he will become the 
fifth space tourist, paying $20 million to board a Russian Soyuz 
rocket and visit the International Space Station.


Mr. Simonyi says he is not disgusted with big, bloated, buggy programs 
like Word and Excel. But he acknowledges that he is disappointed 
that we have been unable to use “our incredible computational ability” 
to address efficiently “our practical computational problems.”


“Software is truly the bottleneck in the high-tech horn of plenty,” 
he said.


Mr. Simonyi began thinking about a new method for creating software 
in the mid-1990s, while he was still at Microsoft. But his ideas 
were so at odds with .Net, the software environment that Microsoft 
was building then, that he left the company in 2002 to found Intentional 
Software.


“It was impractical, when Microsoft was making tremendous strides 
with .Net, to send somebody out from the same organization who says, 
‘What if you did things in this other, more disruptive way?’ ” he 
said in the January issue of Technology Review.


For once, that overfavored word — “disruptive” — is apt; intentional 
programming is disruptive. It would automate much of software development.


The method begins with the intentions of the people inside an organization 
who know what a program should do. Mr. Simonyi calls these people 
“domain experts,” and he expects them to work with programmers to 
list all the concepts the software must possess.


The concepts are then translated into a higher-level representation 
of the software’s functions called the domain code, using a tool 
called the domain workbench.


At two conferences last fall, Intentional Software amazed software 
developers by demonstrating how the workbench could project the intentions 
of domain experts into a wonderful variety of forms. Using the workbench, 
domain experts and programmers can imagine the program however they 
want: as something akin to a PowerPoint presentation, as a flow chart, 
as a sketch of what they want the actual user screen to look like, 
or in the formal logic that computer scientists love.


Thus, programmers and domain experts can fiddle with whatever projections 
they prefer, editing and re-editing until both parties are happy. 
Only then is the resulting domain code fed to another program called 
a generator that manufactures the actual target code that a computer 
can compile and run. If the software still doesn’t do what its users 
want, the programmers can blithely discard the target code and resume 
working on the domain workbench with the domain experts.


As an idea, intentional programming is similar to the word processor 
that Mr. Simonyi developed at PARC. In the jargon of programming, 
Bravo was Wysiwyg — an acronym, pronounced WIZ-e-wig, for “what you 
see is what you get.” Intentional programming also allows computer 
users to see and change what they are getting.


“Programming is very complicated,” Mr. Simonyi said. “Computer languages 
are really computer-oriented. But we can make it possible for domain 
experts to provide domain information in their own terms which then 
directly contributes to the production of the software.”


Intentional programming has three great advantages: The people who 
design a program are the ones who understand the task that needs 
to be automated; that design can be manipulated simply and directly, 
rather than by rewriting arcane computer code; and human programmers 
do not generate the final software code, thus reducing bugs and other 
errors.


NOT everyone believes in the promise of intentional programming. 
There are three common objections.


The first is theoretical: it is based on the belief that human intention 
cannot, in principle, be captured (or, less metaphysically, that 
computer users don’t know what people want).


The second is practical: to programmers, the intentional method constitutes 
an “abstraction” of the underlying target code. But most programmers 
believe that abstractions “leak” — that is, they fail to perfectly 
represent the thing they are meant to be abstracting, which means 
software developers must sink their hands into the code anyway.


The final objection is cynical: Mr. Simonyi has been working on intentional 
programming for many years; only two companies, bound to silence 
by nondisclosure agreements, acknowledge experimenting with the domain 
workbench and generator. Thus, no one knows if intentional programming 
works.


Sheltered by Mr. Simonyi’s wealth, Intentional Software seems in 
no hurry to release an imperfect product. But it is addressing real 
and pressing problems, and Mr. Simonyi’s approach is thrillingly 
innovative.


If intentional programming does what its inventor says, we may have 
something we have seldom enjoyed as computer users: software that 
makes us glad.


Jason Pontin is the editor in chief and publisher of Technology Review, 
a magazine and Web site owned by M.I.T. E-mail: [pontin-:-nytimes-:-com].

just one quick glance at the list of functions for arrays, and I 
just want to run screaming back to REBOL :-)

Ashley, sql-protocol generates the code used to extract and join 
the data is grouped in 2 functions :
- make-do-select
- make-do-loop

They receive the column list, the table list (a block of table/alias 
pair), the where code to apply and the database (the port).


If you provide these parameters and change the code to invoke RebDB 
fuction to get the data, you will have a basic join implementation 
for RebDB. You can use it and extend it for RebDB, if you want, I 
will be happy if you do so.

help db-update is a good start. ;) For a full list of db functions 
just enter "help db-" at the console.

Are we storing these functions in altme, or the mailing list, or 
some other more accessible archive?

A list of all the functions is found here: http://pyopengl.sourceforge.net/documentation/manual/index.xml
Scroll down to see the GLUT functions.

LIST-VIEW is also very monolithic. the filtering and search functions 
don't really belong there. we need to separate that to make it more 
flexible for cases where you only need filtering or searching but 
not display.

If anyone is interested, there is a task that needs to be done:


We want to list all functions in R3 vs. all functions in R2, so you 
can have a direct reference to compare each function between the 
two. This will help in listing those subtle changes that R3 has in 
functions and there will be many more subtle changes when unicode 
releases are done. This is only meant to be on a per-function basis 
and not for higher level ways to do things

I suggested thereby that we output the internal help of all functions 
in R2 and R3 in a two-column table with R2 to the left and R3 to 
the right. Similarly for all mezzanines, we would output the source 
code to each function in a separate two-column table of the same 
format.
When that is done, it needs to be formatted for DocBase.


If anyone is interested in doing that, just signal it in this group.

IMO rebrowse should be far away in our todo list. So much core capabilities 
was missing in the first R3 released.

When i read that for Carl, [parse] evolutions must be downsized the 
most as possible (while I believe this is one of the most important 
functions 

in Rebol), i have still some doubts how priorities are well defined.

Adrian, what Brian is proposing will get you most of what you want, 
but what you are asking for seems to be a bit to specific and from 
my perspective doesn't add enough value to be worth the time to implement. 
 With intuitive sorting you'ld get all of the functions that require 
both an Integer! and a String! first followed by those that require 
an Integer! or a String!.  About 80% of the reason that I actually 
use Help is to see the order in which a function expects it's arguments 
to be in.  Searching for [Integer! String!] will list the functions 
that opperate on a string and require an index to that string at 
the top of the list and I think that's what you're really looking 
for.  Some people think in oppisite directions and want to declare 
the index first and others want to declare the string first.  It's 
just a matter of preference and doesn't change what the function 
does.

LIST-DIR is one of the console interactive functions, so it is acceptable 
for it to have an optional parameter without a refinement - otherwise 
you should avoid that method. The function you should use inside 
code, rather than interactively, is READ.

When investigating the creation of a MAP function in REBOL 2, I found 
that sending functions with refinement to map required some extra 
work (the need for a DO). The rules about get-words as arguments 
has changed in REBOL 3. Maybe I should talk to Carl about it, but 
I could discuss it with you guys first to not disturb Carl too much. 
First a REBOL 2 version of MAP, that can't cope with refinements:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r f 
i] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]


f is the function, l the list and r the result. i is an item in the 
list. The critical part is

append r f i


The function f is evaluated taking the argument i. Easy to read and 
understand. But it can't cope with refinements, which are seen as 
the path! datatype. Example:

>> map sine/radians reduce [0 pi / 6 pi / 2]
== [sine radians sine radians sine radians]


This can be fixed by putting a DO before f. Now it works both with 
and without refinements:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
f i] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]
>> map sine/radians reduce [0 pi / 6 pi / 2]
== [0.0 0.5 1.0]

In REBOL 3, the function is not evaluated:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r f 
i] r]
>> map sine [0 30 90]
== [sine sine sine]

Including DO just makes it worse:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
f i] r]
>> map sine [0 30 90]
== [make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]] make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]] make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]]]

To make map behave correctly, I have to do something like:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
reduce [f i]] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]
>> map sine/radians reduce [0 pi / 6 pi / 2]
== [0.0 0.5 1.0]

Is this ok and accepted behaviour? Will it break many scripts?
(Sorry for the long post, but I wanted to be precise.)

just thought I'd share this list I built while coaching someone in 
using liquid last night...

SANITY PRESERVING KNOWLEDGE WHEN USING LIQUID:
--------------------------------------------


#1:  liquid isn't a bully  - liquid shares its state, but asks for 
data (pulls, observes, etc) from its subordinates ("parents"), not 
the other way around (it doesn' push or force feed, like a highly 
inneficient signal messaging engine).


#2:  liquid is lazy by default - unless a plug or one of its observers 
 ("children") is stainless, nothing will process automatically (thus, 
faces usually are set to stainless, so that they refresh automatically).

#3:  liquid has several computing modes in a single base class.  
  * linking is for once sided dependencies
  * piping is for inter-dependencies or synchronisation
  * containment is for data storage
  * linked-containment is for processed data storage   


#4:  liquid mutates - plugs automatically change computing modes 
when you call some methods like linking, piping and filling.  depending 
on the order of these operations, a plug may "stick" to its previous 
computing mode.  e.g. a piped node remains piped, even you attempt 
to link it to something.


#5:  liquid is alive - remember that as you are setting up a liquid 
network, your plugs will start receiving messages as you are building 
up the tree, meaning that the process() (and other) functions might 
be triggered before every expected connections are done. always verify 
the integrity of the data before starting the process.  (i just got 
stumped by this one again, 5 minutes ago).


#6:  liquid is a collection of droplets - each plug should do one 
thing or manage one step of a process.  the more you break up the 
network, the better you will be at making it stable, reusable, flexible, 
and fast.


#7:  liquid is highly memory efficient - !plug uses shared classes. 
 so all the liquid operations are in a sub-object called a valve. 
 Thus, when you call internal functions, remember they are within 
the valve, and you must supply the plug as its first argument.  my-plug/valve/stats 
my-plug


#8:  liquid is volubile - its slim-based verbose & indented console 
printing engine (vprint) is YOUR BEST FRIEND.  use it profusely, 
to understand the chain of events and what the hell is going on.

normally you have to know that whenever the list changes, you have 
a slew of functions to call, labels to update, what if the cursor 
changes, due to some insertion, deletion, what if the current selection 
is deleted... all examples which have to be handled globally... and 
the more the application grows, the hairier it becomes.

Janko: I have in my todo list a full virtual system to add to Cheyenne 
allowing embedding webapps in a encapped Cheyenne. It can be done 
by replacing every filesystem accessing functions (DO, LOAD, READ, 
WRITE,...) by custom ones getting files from memory. The hard part 
is to integrate such approach within Cheyenne preserving perfomances 
for normal filesystem accesses while avoiding redundant code, this 
needs time for designing and prototyping.


I can't see an easy way to protect you webapps right now, but maybe 
other might have found a way to do that?

SVN r96 -> r103 (most of new features were suggested by Carl)  


FEAT: encapped Cheyenne binaries now returns 0 (or, in case of panic, 
a REBOL error code) on exit

FEAT: (UNIX) Added a new command line option: -V or --version. Displays 
Cheyenne's version, then quits.

FEAT: (Windows) Cheyenne's version is now displayed in the tray icon 
help message.

FEAT: RSP debug mode extended to display tail of trace.log file using 
a new [show trace] button.

FEAT: RSP debug bar look improved, menu horizontal alignment fixed, 
direct link to RSP API online
documentation added.

FEAT: RSP errors are now displayed in an overlay popup instead of 
being inlined in the page.

FEAT: RSP debug bar javascript code footprint reduced to a single 
object: rspdbg (avoids polluting global namespace)

FEAT: new RSP API function: debug. Switches the debug mode on or 
off, for the current RSP script.

FEAT: new API function: debug?. Returns TRUE if debug mode is active.

FEAT: 'debug config keyword definition extended to accept an optional 
block of parameters.

FEAT: RSP session/start now returns the session/active? flag as result.

FEAT: (UNIX) Added a new boot option: -h or --help. Displays the 
command line syntax help and quits.

FEAT: Improved RSP function 'validate to accept default values for 
optional parameters when using
the /full refinement.

FEAT: now plain REBOL scripts can also be run by the RSP engine! 
(see www/show.r)

FEAT: new RSP API function: emit. Does a REDUCE on its argument before 
APPENDing to response/buffer.

FEAT: added new RSP syntax for emit-action : <%? ... %>. Does the 
same as 'emit, but inlined in a
template page.

FIX: (Windows) improved child processes termination with a more graceful 
method using JobObject API

FIX: (UNIX) optimized child processes termination using a kill() 
routine! wrapper instead of CALLing the shell command
FIX: flush HTTP logs in cache on exiting.

FIX: mod-userdir was still commented in config file modules list, 
disabling user/group keywords in httpd.cfg

More info on the new RSP functions in changelog.txt file.

Once a ticket is dismissed, what is the proces for it getting to 
closed?
 I have been wondering that same thing (I'm the reviewer).

Carl and been in a hole generating R3 documentation so he hasn't 
been available to make policy decisions, but that would be the job 
of Carl and the reviewers (just me right now, want to volunteer?). 
However, I think "dismissed" should be removed from the stats and 
current list just like "closed", since it is useful to make the distinction 
between them for documentation purposes.

I think it would be better to exclude 

wishes" from the front-page stats too" Please don't. All requests 
for new functions or options are marked as wishes, so we need to 
keep track of those too if they aren't dismissed.

The other thing that gets something bumped up in priority at this 
point is whether it is an easy fix, for great user benefit, and applies 
to functions or code that we are going over for other reasons now 
anyways. Your DELINE bug is one of those, Kaj. There are more severe 
bugs in that function that have already put it on the priority list, 
your reported bug should be easy to fix too, it affects a real current 
user base in a significant way, and it hints at the possibility of 
a worse hidden problem. These combined make #1794 a near-term priority.

==================
Current video list (ver 2)
==================

- What is the actual architecture here?

- Times Roman font is ugly

- Welcome page needs a better looking welcome page (put it in a nice 
standard box)
- Stealing Vista UI on video is a copyright infringement.

- Bottom controls (just under 3 video frames) were hidden when I 
first came in (I needed to pull the iframe down).
- "Who is online" needs to be a list on the left side.

- The chance to send video took about 3 minutes, so I did not see 
how to do this.  The video box should say it will do this for you 
at some point.
- Chat box shows "viewer n" as opposed to <name>
- Each iframe seems to come up too small.
- Chat buffer is too small (and allows too few characters.

- Echo is a big problem (Other systems have this problem, but TeamSpeak 
less than others).


= Screen shot capture = 


- Change [Download screen sender] to [Download Windows Screen Sender]. 
 Or just ad Windows icon.

- Add icons to all functions at bottom, like an upload icon for Upload.

- Rename [RockFactory] to same name as it thinks it is PNGShot.exe. 
 My virus catcher was NOT happy about this program running.

What I've noticed about Carl's styles is that he tries to do as much 
of that intra-face communication inside the styles.


That is simple to do at first, but doesn't scale very well, because 
we will have a lot of different styles.


Still, some parts could be inherent to the face or style, in that 
the face or style holds a list of actions to perform and then some 
type of evaluator (I've never built these things, so I don't know 
what to call it). There is DO-STYLE, but a formalization of how to 
store the actions inside the face is needed, both when specifying 
face attachments in the layout and when accessing the face attachments 
using a general access function like DO-STYLE or DO-FACE.


The formalization is needed to allow a scalable number of actions 
or attachments stored in each face. This could simply be a block 
of blocks or functions that are bound to both source and target face. 
In order to trigger the action, just DO the block or function and 
the magic unfolds.

...also not having to use composed/reduced blocks all the time.


If you had look at the concept demo I posted above there is no sigle 
forced compose or reduce(ofcourse except the possible internal native 
parser processing) applied on the DRAW block using this method.


getting info like (x,y) coordinate of current bspline curve at length 
100 pixels from an end.  
getting intersections between complex shapes 
like splines and polygons, xformed.
bounding boxes of things, calculated 
points of displayed letters.


Agreed, being able te get calculated coordinates of bsplines was 
planned addition, though not yet implemented.

Not sure about the intersections. I think you would need to use external/third-party 
code for that.
Bounding boxes, yes that is/was also planned.

But these ale more like helper functions which doesn't need to have 
any 'draw elements' access. It's enough to provide whole/partial 
draw block to get proper results.


if there where a unified method which just keeps the persistent data...


The DRAW dialect block is the persistent data IMO. And you can build 
any other dialect/system over it.

Don't be fooled by the result you are seeing. The internal structure 
of the data is almost identical as described in the DRAW block but 
in different format.

All the calculations are done on-the-fly using diferent parts of 
the pipeline setup. For example:


coordinates(almost same as in DRAW definition)->curve_converter->trasformer->rasterizer->renderer


there is not any persistent storage between 'coordinates' and 'rasterize' 
phases (that would be memory overkill to store all the approximated 
curves etc.)..the result is directly rasterized on the fly.

So in fact there is no static 'list of vertices or whateve' of the 
resulted image, everything is dynamic from the time you pass your 
DRAW definition to the engine.


...and we can move it around/manipulate it without needing to store 
it as a block of dialect, I could build my own specific and much 
cleaned up dialects or graphic engines without needing to go through 
the draw dialect like I do know.
 

See the concept demo. I'm using one single DRAW block for all the 
objects and I can access/manipulate them without any complex code. 
There are no limits.


Myself, I have no use for most of the draw dialect, it just complicates 
my work, by getting in my way.


ok, so show me example of the form you would like to use for drawing. 
Is there any existing system which uses your expected behaviour?

Tags are really trivial. They are just a list of words and we have 
a few TAG functions to set/unset/inspect them during runtime. It's 
entirely up to styles or the higher level code to use tags correctly 
and this is for example done with face navigation.

Guys, time to crank up the volume and build a concrete roadmap for 
the GUI. I have a suggestion to further accelerate the development 
of the GUI: RM Asset will over time require some specific, but complex 
styles, that the community will need as well. We are developing a 
SCRUM tool, which you will need to use as a basis for discussions 
and development of these styles. Consider it also training to become 
a good style developer. For any needs, Cyphre, Bolek, Ladislav and 
I will be available to extend the UI base as needed to create the 
styles mentioned below. We also provide examples, training and help.


Many of these styles are focused for development of particular types 
of applications that open many, small windows inside a large work 
area for flexible construction of data analysis tools and other traditional 
Windows or Linux applications.


It could be a combination of how graphics shader networks are built 
(though without the need for zooming), to regular multi-document 
management. The ultimate goal is to build styles that allow a highly 
user configurable multi-document GUI to be described, using only 
the R3 GUI dialect and some helper functions that we already have.

These styles are generic enough to be usable in plenty of apps.

Inspirations for window arrangements:


http://houdini.dreamerzstudio.net/wp-content/uploads/2010/05/reflectiveShaderNetwork.jpg
http://www.codeproject.com/KB/docview/TabbedMDI/TabbedMDI.gif

Inspiration for segmented area management:


http://www.solidsmack.com/wp-content/uploads/2010/12/modo_501_RayGL_sample_002.jpg
http://jedit.sourceforge.net/jedit-snap-12.png

A list of general styles that definitely are needed:


- Style for doing multi-document window management, using various 
arrangements, window linking features, as borrowed from apps like 
Photoshop.

- Style for segmented area management, editable by users, for arranging 
tool areas, view areas. Segments are adjustable in size. Inspiration 
is JEdit and Modo.
- Multi-document window style, for use in window management style
- Tool window style, for use in window management style

- Tear-off style for toolbars and tool windows, for use in window 
management style

- Regular Windows-style menu bar with submenus, also for right-click 
popup menus.

More specific styles that will be needed later:


- High-performance style for graphing points and curves in a coordinate 
system, with zooming and panning.
- Gannt chart style: http://en.wikipedia.org/wiki/Gannt_Chart
- Harvey Ball style: http://en.wikipedia.org/wiki/Harvey_Balls
- Year calendar style
- Month calendar style
- Week calendar style
- Day calendar style

- MacOSX style tag field: http://kitara.nl/wp-content/uploads/2010/05/31.png

- Console style for input and listing results. This could eventually 
grow into the base for a View based R3 console.

- Highly ergonomic numeric input styles, that support unit conversion, 
inline math.

The question is where to start and what fits with you.


The time table is simply ASAP, and preferrably want some results 
within the next 2 months.


If you are planning R3 apps soon, it would be a good idea to have 
a look at the list to see where you may be able to contribute, as 
the GUI moves to beta status. RM Asset needs to spend time building 
end-user apps for R3 and the GUI is becoming ready, except for the 
above mentioned styles.

are there any accessor functions, how to easily list face, pane, 
style etc. structure? I mean without references? I would like to 
see (e.g. in docs, or by query) the ability to list face, gob, style 
structure ...

list of the *CONTENT functions (current names):

SET-PANEL-CONTENT
CLEAR-PANEL-CONTENT
INSERT-PANEL-CONTENT
APPEND-PANEL-CONTENT
CHANGE-PANEL-CONTENT
REMOVE-PANEL-CONTENT

I expect that the best use will be either making is-it-an-error-or-not 
changes like the above, or simplified versions of functions, perhaps 
for sandboxing. So remember this: If you have a nice, friendly native 
function with some advanced, evil options, put the most evil ones 
at the end of the list, so they can be hidden later if need be.

es5 adds a lot of new tricks for playing around with values.  the 
args list can be retrived, applied, changed, etc.  I'll admit the 
part about the code body is a bit fuzzy in my mind, but I seem to 
remember that you could play around with it in some way too.
 

playing around with the functions isn't exactly the same but the 
end results are very similar IMHO. 

especially since hot-patching isn't allowed in R3 anymore.

Graphics extension loads:

http://rebol.hmkdesign.dk/files/r3/gui/217.png

List of graphics functions:

http://rebol.hmkdesign.dk/files/r3/gui/218.png


There was a small demo to display a random collection of gobs, but 
a bug in the host kit prevents me from taking a screenshot.

Some counterexamples where we messed this up:

- "functions" have side effects so they aren't really functions, 
they are procedures with return values.

- "closures" aren't really closures, though they are closer to that 
than REBOL "functions" are.
- "contexts" aren't contextual
The list goes on.

The module model is stable for now, and has no current errors in 
the mezzanine code, though OSX has some errors in RESOLVE. When tasks 
are supported better there will need to be some minor underlying 
changes, but not many because the module system was written with 
the proposed multitasking model in mind. The module list hasn't been 
locked down from a security standpoint, though its layout was designed 
with that in mind. There are still bugs and missing features in the 
(UN)PROTECT functions that are blocking the locking down of R3, so 
don't run untrusted code yet.

That would fail for = and all other functions that allow the any-type! 
value (for unset! and error! support), and make it difficult to understand 
the help of all op functions, which use the typespec of the first 
argument for documentation purposes. Plus, the argument list for 
the op! is taken directly from the function it is derived from - 
it can't and shouldn't be able to be specified separately.

DO is seductive, because sometimes I want to create (easily) a "dialect 
environment" and just use DO to evaluate my dialect., safely and 
securely. 


Is there a security page in the docs (I don't see one in the R3 docs 
right now)? If not, that would be good to have. If we have a list 
of functions and operations you shouldn't use on untrusted data, 
and what the risks are, that's a good start.

Here is my short list (I am sure I forgot to mention a lot of things 
other people may find important)

Advantages of R3:

- new datatypes

-- map!, money!, percent!, closure!, module!, typeset!, command!, 
get-path!, 
- enhanced objects
- enhanced errors
- support for UNICODE strings
- enhanced bitsets (support for UNICODE)
- enhanced pairs
- 64-bit integers

- better conversions (to binary! and back)

- enhanced PARSE
-- new keywords added
- enhanced MOLD
-- improved MOLD/ALL
- enhanced LOAD
- some functions became natives
-- native APPEND
- more complete set of comparison functions
-- EQUIV? added
- much better RANDOM

- enhanced loops (CONTINUE)

- enhanced debugging capabilities (call stack)
- enhanced protection (PROTECT)

- improved GC

- more open (the host-kit is open source)

Disadvantages:

- missing list! (the demand for the datatype was low)

- missing hash! (for the majority of applications map! should be 
faster and more comfortable)

- no adequate substitute for the [throw] function attribute exists 
yet
- missing struct! (for substitute, see extensions)

Bundle the modules as what Carl now calls "optionally included". 
Also keep a list of scheme prefix to module name, and just auto-import 
the module from this list when a scheme is used in on of the scheme 
action functions (READ, OPEN, ...).

For the sake of completeness, here are the highlights of the alpha 
108 changes:

- Script headers can have an options block, a simple block of flag 
words. User extensible.

- The standard script header now has a lot fewer words in it. More 
stuff is optional or in the options block.

- Script compression, either binary and base 64 binary! encoded. 
Automatic, transparent.

- Script checksums, both to verify the script and for IMPORT to compare 
with. Applies to decompressed source.

- An optional script length header field (like http's Content-Length). 
This allows binary script embedding.

- Internal support for getting the end of an embedded script, so 
a multi-loader is possible.

- The 'content and 'isolate header fields are changed to option words. 
The content is still saved to a 'content header field.

- The 'content field, if set, is set to the start position of the 
script proper, even if there is stuff before it.

- The whole system/contexts/system concept is gone, as part of the 
system restructuring. Now we have SYS.

- The system/contexts/exports concept is gone too, replaced by a 
not-module-specific runtime library called LIB.

- The old type: 'extension is now the 'extension header option word. 
The only module type is 'module. And it's optional for most code.

- Mixins are now called "private modules", and are flagged by the 
'private option word. And they can have names.

- Private modules can be added to the system modules list (because 
of the names). This lets them be reused without being reloaded.

- Unnamed modules are now prohibited (until alpha 109, where they 
become private modules that reload every time).

- Delayed modules, which can be partially loaded and then not fully 
made until they are imported. Use the 'delay option word.

- A HIDDEN module source keyword, which applies PROTECT/hide to a 
word or words. Acts like the EXPORT keyword.

- Better errors are triggered when the bad things happen. Including 
new error codes.

- DO and MAKE--MODULE intrinsics are now in sys, as DO* and MAKE-MODULE*. 
No more system/intrinsics.

- DO-NEEDS is no longer exported (it's in sys). IMPORT block is a 
public alias for DO-NEEDS anyways.

- MODULE now makes modules that act more like those in script files. 
And has /mixin support too.

- A whole bunch of changes and fixes to native functions to support 
the above stuff.